AGARD-CP-581 


AGARD-CP-581 


ADVISORY  GROUP  FOR  AEROSPACE  RESEARCH  &  DEVELOPMENT 

7  RUE  ANCELLE,  92200  NEUILLY-SUR-SEINE,  FRANCE 


AGARD-CP-581 


ADVISORY  GROUP  FOR  AEROSPACE  RESEARCH  &  DEVELOPMENT 

7  RUE  ANCELLE,  92200  NEUILLY-SUR-SEINE,  FRANCE 


AGARD  CONFERENCE  PROCEEDINGS  581 

Advanced  Architectures  for  Aerospace 
Mission  Systems 

(Architectures  futures  pour  I’avionique  de  gestion  de  mission) 


Papers  presented  at  the  Mission  Systems  Panel  6th  Symposium  held  in  Istanbul,  Turkey, 
14-17  October  1996. 


DTic  quality  iltspecteb  ^ 


North  Atlantic  Treaty  Organization 
Organisation  du  Traite  de  i’Atiantique  Nord 


19970827  101 


The  Mission  of  AGARD 


According  to  its  Charter,  the  mission  of  AGARD  is  to  bring  together  the  leading  personalities  of  the  NATO  nations  in  the 
fields  of  science  and  technology  relating  to  aerospace  for  the  following  purposes; 

—  Recommending  effective  ways  for  the  member  nations  to  use  their  research  and  development  capabilities  for  the 
common  benefit  of  the  NATO  community; 

—  Providing  scientific  and  technical  advice  and  assistance  to  the  Military  Committee  in  the  field  of  aerospace  research 
and  development  (with  particular  regard  to  its  military  application); 

—  Continuously  stimulating  advances  in  the  aerospace  sciences  relevant  to  strengthening  the  common  defence  posture; 

—  Improving  the  co-operation  among  member  nations  in  aerospace  research  and  development; 

—  Exchange  of  scientific  and  technical  information; 

—  Providing  assistance  to  member  nations  for  the  purpose  of  increasing  their  scientific  and  technical  potential; 

—  Rendering  scientific  and  technical  assistance,  as  requested,  to  other  NATO  bodies  and  to  member  nations  in 
connection  with  research  and  development  problems  in  the  aerospace  field. 

The  highest  authority  within  AGARD  is  the  National  Delegates  Board  consisting  of  officially  appointed  senior 
representatives  from  each  member  nation.  The  mission  of  AGARD  is  carried  out  through  the  Panels  which  are  composed  of 
experts  appointed  by  the  National  Delegates,  the  Consultant  and  Exchange  Programme  and  the  Aerospace  Applications 
Studies  Programme.  The  results  of  AGARD  work  are  reported  to  the  member  nations  and  the  NATO  Authorities  through  the 
AGARD  series  of  publications  of  which  this  is  one. 

Participation  in  AGARD  activities  is  by  invitation  only  and  is  normally  limited  to  citizens  of  the  NATO  nations. 


The  content  of  this  publication  has  been  reproduced 
directly  from  material  supplied  by  AGARD  or  the  authors. 


Published  July  1997 

Copyright  ©  AGARD  1997 
All  Rights  Reserved 

ISBN  92-836-0044-4 


Printed  by  Canada  Communication  Group  Inc. 

(A  St.  Joseph  Corporation  Company) 

45  Sacre-Coeur  Blvd.,  Hull  ( Quebec),  Canada  KIA  0S7 


ii 


Advanced  Architectures  for  Aerospace 
Mission  Systems 

(AGARD  CP-581) 


Executive  Summary 


The  sixth  symposium  of  the  Mission  Systems  Panel  was  prompted  by  major  changes  that  are  expected 
in  the  configuration  of  future  weapon  platform  mission  systems.  At  present  these  usually  consist  of  a 
variety  of  complex  and  costly  stand-alone  functions  (EW,  fire  control,  communications  and  so  on)  but 
there  is  a  move  towards  more  efficient,  effective  and  affordable  advanced  architectures  which  embrace 
the  whole  mission  systems  suite  and  are  characterised  by  close  functional  integration  and  greatly 
improved  data  interchange  and  management.  As  well  as  architectural  concepts,  applications,  and 
technologies,  the  symposium  included  as  a  topic  the  use  of  commercial  off-the-shelf  components 
(COTS)  and  a  concluding  discussion  on  the  impact  of  advanced  architectures  on  affordability. 

Key  issues  addressed  by  the  symposium  were: 

•  The  high  cost  and  complexity  of  present  mission  systems  -  now  approaching  40%  of  total  weapon 
platform  cost; 

•  The  need  to  integrate  the  functions  performed  by  the  platform  in  order  to  reduce  cost  and  weight 
penalties  incurred  by  individual,  specialized  systems; 

•  The  improvements  in  reliability,  maintainability,  and  functional  reconfigurability  from  common 
digital  modules,  common  high-level  software  and  shared  RF  and  EO  apertures; 

•  The  extent  to  which  flexible  hardware  and  software  architecture  could  lead  to  easier  upgrades  and 
improved  mission  reliability. 

The  symposium  covered  a  wide  range  of  applications  and  highlighted  the  developments  taking  place  on 
both  sides  of  the  Atlantic  in  signal  and  data  processing/communications  and  related  areas  of  advanced 
information  technology.  These  developments  hold  out  the  promise  of  highly  integrated  mission  systems 
that  will  be  much  more  adaptable,  fault  tolerant  and  affordable  than  present  systems.  Much  of  the 
hardware  and  software  technology  is  commercially  inspired,  making  the  drive  towards  utilization  of 
COTS  components  and  technologies  a  feasible  goal,  though  account  must  be  taken  of  those  key  areas  of 
avionics  in  which  the  requirements  will  remain  in  advance  of  eommercial  developments,  and  of 
military  systems’  extended  life  spans  to  ensure  they  do  not  end  up  with  obsolete  hardware  and  software 
standards  that  are  no  longer  supported  in  the  market  place. 

The  symposium  was  rated  by  the  participants  from  significant  to  extremely  valuable. 
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Architectures  futures  pour  I’avionique 
de  gestion  de  mission 
(AGARD  CP-581) 

Synthese 

La  decision  d’ organiser  le  sixieme  symposium  du  Panel  AGARD  des  systemes  de  conduite  de  mission 
a  ete  motivee  par  les  grands  changements  qui  sont  attendus  dans  la  configuration  des  futures  plates- 
formes  de  systemes  d’armes.  A  present,  celles-ci  consistent  en  general  en  un  grand  nombre  de  fonctions 
autonomes  complexes  et  couteuses  (EW,  conduite  de  tir,  communications  etc.),  mais  une  tendance  se 
dessine  en  faveur  d’ architectures  avancees  plus  efficaces,  performantes  et  abordables.  Ces  architectures 
couvrent  1’ ensemble  des  equipements  de  conduite  de  mission  et  sont  caracterisees  par  une  integration 
fonctionnelle  tres  poussee,  une  meilleure  gestion  et  un  meilleur  echange  des  donnees.  En  plus  des 
applications,  technologies  et  concepts  architecturaux,  le  symposium  a  examind  la  question  des 
composants  du  commerce  (COTS)  lors  d’une  discussion  de  cloture  sur  I’impact  des  architectures 
avancees  sur  le  concept  du  cout  de  possession  acceptable. 

Les  principaux  sujets  abordes  lors  du  symposium  etaient  les  suivants  : 

•  le  cout  eleve  et  la  complexite  des  systemes  de  mission  actuels  -  il  avoisine  40%  du  cout  global  de 
la  plate-forme  d’armes  ; 

•  la  necessite  d’integrer  les  fonctions  remplies  par  la  plate-forme  afin  d’attenuer  les  effets 
penalisants  en  termes  de  cout  et  de  poids  pour  les  systemes  individuels  specialises  ; 

•  les  ameliorations  en  ce  qui  concerne  la  fiabilite,  la  maintenance  et  la  reconfiguration 
fonctionnelle  a  partir  de  modules  numeriques  communs  et  de  logiciels  communs  de  haut  niveau  a 
ouvertures  RE  et  EO  partagees  ; 

•  la  mesure  dans  laquelle  les  architectures  materielles  et  logicielles  souples  pourraient  faciliter  les 
extensions  et  ameliorer  la  fiabilite  operationnelle. 

Le  symposium  a  couvert  un  grand  eventail  d’ applications  possibles  en  mettant  T  accent  sur  les 
developpements  en  cours  des  deux  cotes  de  I’Atlantique  dans  le  domaine  du  traitement  du  signal  et  des 
donnees,  des  communications  et  les  domaines  y  associes  des  technologies  avancees  de  T information. 
Ces  developpements  promettront  d’aboutir  sur  des  systemes  de  conduite  de  mission  plus  souples,  a 
meilleure  tolerance  de  pannes  et  plus  abordable  financierement  que  les  systemes  actuels. 

Bon  nombre  des  technologies  materielles  et  logicielles  ont  une  vocation  commerciale.  L’objectif  de  la 
mise  en  oeuvre  de  ces  technologies  et  composants  COTS  est,  par  consequent,  tout  a  fait  realisable. 
Cependant,  dans  cette  demarche,  il  devra  etre  tenu  compte,  d’une  part  des  domaines  cles  de  I’avionique 
ou  les  caracteristiques  techniques  demandees  seront  toujours  en  avance  sur  les  developpements 
commerciaux  et,  d’autre  part,  des  cycles  de  vie  prolonges  des  systemes  militaires.  Ceci  afin  d’eviter  la 
situation  ou  les  normes  du  materiel  et  des  logiciels  utilises  seraient  depassees;  ce  qui  aurait  des 
consequences  negatives  sur  leur  maintenance. 

Les  participants  a  ce  symposium  Font  juge  pour  le  moins  digne  d’interet  et  meme  d’une  tres  grande 
valeur. 
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Theme 


Mission  systems  in  the  past  were  developed  primarily  as  stand-alone,  dedicated  suites  to  perform  a 
single  function  such  as  EW,  fire  control,  communication,  etc.  It  is  becoming  increasingly  clear  that 
future  mission  systems  must  be  designed  from  the  perspective  of  the  total  set  of  functions  that  will  be 
performed  by  the  platform.  This  is  being  driven  by  the  fact  that  the  cost  of  mission  systems  has  risen 
dramatically  in  recent  years.  For  example,  the  mission  systems  cost  for  aircraft  is  approaching  40%  of 
the  total  weapon  system  fly-away  costs.  Furthermore,  the  weight  of  individual  specialized  mission 
systems  is  becoming  exorbitant. 

Also,  higher  reliability,  maintainability  and  the  ability  to  reconfigure  the  functions  performed  are 
definite  advantages  of  advanced  architectures.  Thus,  future  mission  systems  will  be  characterized  by  a 
robust  architecture,  common  digital  modules,  common  high  level  software  utilizing  a  standard  language 
and  shared  RF  and  EO  apertures  across  functions.  The  architecture  will  define  the  interfaces  between 
the  common  and  shared  modules  used  to  implement  the  required  functional  performance.  The 
architecture  will  also  define  the  interfaces  to  be  used  for  the  software  modules.  A  flexible  hardware  and 
software  architecture  will  permit  easy  upgrades  through  incorporation  of  ever-improving  hardware  and 
software  technology.  Advanced  architectures  will  also  permit  substantial  improvements  in  mission 
reliability  due  to  the  great  flexibility  in  reconfiguring  the  system  hardware  and  software  to  minimize  the 
impacts  of  module  failures.  An  integrating  element  uniting  the  components  will  be  provided  through 
sensor  and  data  fusion/correlation  processes  that  will  be  an  essential  element  of  the  advanced 
architectures. 


Theme 


Dans  le  passe,  les  systemes  de  conduite  de  mission  etaient  developpes  principalement  comme  systemes 
autonomes  specialises,  destines  a  remplir  une  seule  fonction  telle  que  la  guerre  electronique,  la  conduite 
de  tir,  les  telecommunications  etc.  II  semble  de  plus  en  plus  evident  que  les  systemes  de  conduite  de 
mission  futurs  devront  etre  con9US  pour  1’ ensemble  des  fonctions  qui  seront  a  executer  par  la 
plateforme.  Cette  approche  s’explique  par  le  fait  que  le  prix  d’achat  des  systemes  de  conduite  de 
mission  a  augmente  de  fagon  sensible  au  cours  des  dernieres  annees.  A  titre  d’exemple,  le  cout  typique 
d’un  systeme  de  mission  aeronautique  modeme  atteint  presque  40%  du  prix  en  etat  de  vol  du  systeme 
d’armes  auquel  il  est  associe.  En  outre,  la  masse  physique  des  systemes  de  conduite  de  mission 
individuels  specialises  pose  de  plus  en  plus  de  problemes. 

Par  contre,  les  architectures  avancdes  peuvent  s’attribuer  un  certain  nombre  d’avantages  concrets  tels 
que  la  fiabilite  et  la  maintenabilite  ameliorees,  ainsi  que  la  possibilite  de  reconfigurer  les  fonctions 
executees.  Ainsi,  les  futurs  systemes  de  conduite  de  mission  seront  caracterises  par  des  architectures 
robustes,  des  modules  numeriques  communs,  des  logiciels  de  haut  niveau  communs  ecrits  en  langage 
standard,  ainsi  que  des  passerelles  RF  et  EO  entre  les  fonctions.  L’ architecture  choisie  definira  les 
interfaces,  entre  les  modules  communs  et  partages  permettant  d’obtenir  les  performances  fonctionnelles 
demandees.  L’ architecture  definira  egalement  les  interfaces  a  adopter  pour  les  modules  logiciels.  Une 
architecture  logicielle  et  materielle  souple  facilitera  les  extensions  par  1’ integration  de  technologies 
logicielles  et  materielles  evolutives.  Les  architectures  avancees  conduiront  a  des  ameliorations 
substantielles  en  fiabilite  operationnelle,  etant  donne  la  grande  souplesse  de  reconfiguration  du  materiel 
et  du  logiciel  systemes,  qui  permettra  de  minimiser  I’impact  des  pannes  des  modules.  Enfin,  les 
techniques  de  detection  et  de  fusionnement/correlation  des  donnees  seront  un  element  essentiel  des 
architectures  avancees ;  elles  joueront  un  role  integrateur,  permettant  de  relier  les  differents  composants 
des  systemes. 
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TECHNICAL  EVALUATION  REPORT 


Stanley  Leek 
8  Sunnyfield 
Hatfield 

Hertfordshire  AL9  .“iOX 
United  Kingdom 


INTRODUCTION 

The  Sixth  Symposium  of  the  Mission  Systems  Panel, 
on  Advanced  Architectures  for  Aerospace  Mission 
Systems,  was  held  in  Istanbul,  Turkey  on  14-17  October 
1996.  It  was  prompted  by  the  need  for  major  change  in 
the  configuration  of  weapon  platfomi  mission  systems 
(at  present,  generally  a  collection  of  stand-alone 
systems  dedicated  to  separate  functions  of  EW,  fire 
control,  communications  and  so  on)  which  are 
becoming  excessively  complex  and  costly. 

The  main  thrust  of  the  Symposium  was  towards  more 
efficient  and  effective  advanced  architectures  that  will 
embrace  the  whole  mission  systems  suite,  emphasising 
functional  integration  and  data  interchange  and 
management.  As  well  as  architectural  concepts, 
applications,  and  technologies,  the  symposium  included 
as  a  topic  the  use  of  commercial  components  and  a 
concluding  discussion  was  devoted  to  the  impact  of 
advanced  architectures  on  affordability. 

Key  issues  that  were  planned  to  be  addressed  by  the 
Symposium  were: 

•  The  high  cost  and  complexity  of  present  •  mission 
systems  -  now  approaching  40%  of  total  weapon 
platform  cost. 

•  The  need  to  integrate  the  functions  performed  by  the 
platfomi  in  order  to  reduce  cost  and  weight  penalties 
incumed  by  individual,  specialized  systems. 

•  The  improvements  in  reliability,  maintainability,  and 
functional  reconfigurability  from  advanced  architec¬ 
tures  that  utilize  common  digital  modules,  common 
high-level  software  and  shared  RF  and  EO  apertures. 

•  The  extent  to  which  flexible  hardware  and  software 
architectures  could  lead  to  easier  upgrades  and 
improved  mission  reliability. 

KEYNOTE  ADDRESS 

In  his  Keynote  Address,  “Requirements  for  Advanced 
Avionics  Systems  Architectures.”  Dipl.-lng.  Jochen 
Potthaus.  Director,  Bundesmat  fiir  Wehrtechnik  und 
Beschaffung  (BWB),  GE.  set  the  scene  for  the  papers 
that  followed  by  focusing  on  the  requirements  for 
advanced  avionics  systems,  architectures,  interoper¬ 
ability  and  standardization,  as  he  saw  them,  and  their 
implications  for  current  ways  of  contracting  and 
building  equipment.  Refening  to  the  rapidly-evolving 
capabilities  of  sensors  and  real-time  computing 
systems,  he  reviewed  the  advanced  operational 


capabilities  and  new  functionalities  they  will  make 
possible,  together  with  their  contribution  in  helping  to 
meet  the  demands  of  the  Alliance  for  flexibility, 
mobility  and  interoperability. 

The  potential  of  a  total  system  approach  to  avionics 
systems  integration  for  containing  costs,  together  with 
advanced  information  handling  and  the  use  of 
commercial  off  the  shelf  components  (COTS)  were 
highlighted  as  important  themes  of  the  symposium.  He 
summarised  the  advantages  achievable  by  advanced 
avionics  systems  under  the  headings:  system  surviv¬ 
ability.  system  availability,  multimission  capability, 
mission  success  probability,  interoperability  and 
deployment,  and  life  cycle  cost. 

He  rounded  off  his  Keynote  Address  by  stressing  the 
need  for  cooperation  and  exchange  of  infonnation 
between  the  NATO  nations  and  expressing  his 
appreciation  to  AGARD  and  the  contributors  to  the 
present  symposium. 

SESSION  I:  TECHNOLOGY  OVERVIEWS 

Mr  Lairy  Ott,  US.  (Symposium  Chairman)  opened 
the  session  by  highlighting  three  areas  of  concern  for 
the  symposium:  architectures,  information  manage¬ 
ment,  and  COTS.  As  an  example  for  later  discussion  he 
commented  on  the  drive  towards  open  architectures  and 
the  potential  difficulties  of  efficient  implementation  in 
existing  aircraft  and  of  commonality  in  architectures 
across  different  classes  of  aircraft.  Also,  information 
management  raises  difficult  questions  regarding  the 
quantity  and  availability  of  information  and  associated 
technology  challenges.  COTS  utilisation  raises  a 
number  of  difficult  issues  in  military  systems’ 
implementation,  such  as  security  and  fault  tolerance. 

The  first  paper  of  the  session,  “Advanced 
Architectures  -  Where  are  We  Going?”,  by  Domae. 
Logan  and  Viney.  of  Northrop  Grumman,  US,  was 
presented  by  Teiry  Domae.  It  addressed  the  issues  of 
advanced  architectures  from  the  perspective  of  the  Joint 
Stn'ke  Fighter,  and  the  evolution  of  open  systems  from 
the  PAVE  PACE  and  PAVE  PILLAR  programmes  of  the 
1980's.  Long  tenn  technology  trends  in  digital  sensor 
processing  and  preprocessing,  analog-to-digital  con¬ 
verters.  lightwave  signal  distribution  and  routing 
technology,  and  portable  and  supportable  software, 
provide  keys  to  affordable  avionics  advances  in  areas 
such  as  future  waveform-independent  electronics 
modules  capable  of  supporting  multifunction  apertures. 
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The  autliors  concluded  that  integrated  arcliitectures  will 
become  the  rule  for  new  systems  or  major  upgrades  and 
noted  the  trend  towards  digitization  of  previously 
analog  functions  with  associated  enhanced  system 
reprogrammability,  plus  the  evolution  of  distributed 
integrated  systems. 

The  paper  given  by  Mike  Williams  that  followed, 
“Infomiation  -  the  Warfighter's  Edge”,  by  Williams  and 
Collier  of  Lockheed  Martin,  US,  was  subtitled  “The 
Joint  Strike  Fighter  and  System-of-Systems”,  which 
indicated  the  focus  of  their  paper  on  the  maximum 
utilization  of  infomiation  systems  in  forthcoming 
military  aircraft  to  improve  their  capability.  Concerns 
with  affordability,  lethality,  survivability  and  support- 
ability  were  discussed  in  terms  of  the  trade-space  of 
ISR  (Intelligence,  Surveillance  and  Reconnaissance), 
C'*  (Command,  Control,  Communication  and 
Intelligence),  Onboard  Systems,  and  CONOPs 
(CONcept  of  operations).  The  authors’  vision  of  the 
emerging  JSF  battlefield  -  elaborated  in  a  description 
of  the  System  of  System.s  requirements  process  -  is  one 
in  which  ISR  and  C^  assets  are  fully  integrated  with  on¬ 
board  systems.  They  concluded  that  a  completely 
autonomous  mission  capability  for  tactical  aircraft  is  no 
longer  affordable  nor  necessary,  and  that  on-board 
sensors  can  be  made  individually  less  complex,  given 
the  ability  of  advanced  on-board  avionics  systems  to 
comelate  large  amounts  of  information. 

In  reply  to  a  question  from  the  Session  Chairman 
regarding  non-concument  infonnation,  the  author 
stressed  the  need  to  balance  all  elements  of  the  trade- 
space,  taking  account  of  the  timeliness  and  accuracy  of 
off-board  information,  and  the  need  for  time-tagging 
and  utilization  of  multiple  sources  for  data  fusion. 

The  final  paper  of  this  session,  “COTS  Joins  the 
Military”,  by  Anderson  and  Stevens  of  Lockheed 
Martin,  US,  was  given  by  Larry  Anderson  who 
presented  an  analysis  of  COTS  products  and  NDl  (Non- 
Development  Items)  in  terms  of  their  ability  to  meet 
affordability  requirements.  However,  to  achieve  the 
potential  of  COTS/NDI  economies  of  scale,  several 
factors  must  be  considered,  including  defence  industry 
involvement  in  commercial  development,  and  the  need 
for  continuous  technology  insertion  in  place  of  present 
lengthy  upgrade  intervals. 

The  authors  cited  their  company’s  participation  in  the 
US  Navy  sponsored  HSDTN  (High  Speed  Data 
Transfer  Network)  working  group,  which  adopted  the 
IEEE  1596-1992  Scalable  Coherent  Interface  (SCI)  as  a 
standard  backplane  network  in  order  to  eliminate  the 
lack  of  bandwidth  and  scalability  of  “party  line” 
backplane  buses.  Their  COTS-based  P"M  strategy  has 
introduced  significant  changes  in  software  architecture 
including  for  example,  commercial  multiprocessor 
systems  using  SCI  in  shared  memory  management  and 
cache  control.  However,  the  authors  also  describe  a 
significant  SCI-based  scalable  multi-processor  system 
(SMPS)  based  on  non-commercial  development  of  a 
high-bandwidth,  fault-tolerant  matrix  switch. 


SESSION  II:  ARCHITECTURES  FOR  MISSION 
SYSTEMS  MODERNIZATION 

The  first  paper  of  this  session.  “Department  of 
Defense  Perspective  on  Open  Systems  Architecture”, 
by  Lt  Col  Glen  T  Logan  of  the  USAF,  addressed  one  of 
the  major  issues  raised  in  the  previous  session.  Col 
Logan  began  with  a  summary  of  the  background 
thinking  to  current  DoD  policy  in  this  area,  resulting 
from  reduced  US  defense  budgets  and  the  recognition 
that  it  can  no  longer  “go  it  alone”.  The  Open  Systems 
Joint  Task  Force  (OS-JTF),  set  up  in  response  to  a  1994 
policy  memorandum  from  the  Under  Secretary  of 
Defense,  was  the  main  subject  of  his  paper. 

The  Task  Force’s  activities  (publicised  on  its  Internet 
World  Wide  Web  Home  Page)  cover  three  main 
activities:  training,  standards,  and  demonstration  pro¬ 
grams.  The  author  mentioned  two  demonstration  efforts 
cuiTently  being  planned:  the  AV-8B  Open  System  Core 
Avionics  Requirements  (OSCAR)  which  would  be 
expected  to  pay  for  itself  in  five  years,  and  the  F-15 
Multi-Pui-pose  Display  Processor;  plus  the  related  Open 
Systems  Ada  Technology  (OSAT)  demonstration  in 
association  with  the  Ada  Joint  Program  Office  and  the 
Joint  Strike  Fighter  Program  Office. 

The  author  agreed,  in  response  to  questions,  that 
there  were  problems  with  changing  industry  standards 
(for  example  the  probable  eventual  disappearance  of 
VME  support)  and  the  suitability  of  commercial 
devices  for  the  military  environment.  Both  questions 
pointed  up  the  need  for  avionics  industi7  involvement 
in  the  early  stages  of  development,  when  any  additional 
cost  could  be  minimised. 

The  next  paper,  “Modular  Avionics  System 
Architecture  Definition  in  the  EUCLID  Research  and 
Technology  Programme  4.1”,  by  A  Marchetto  of  Alenia 
Aeronautica,  IT,  described  what  has  been  the  first 
programme  of  a  more  general  Modular  Avionics 
initiative  (CEPA  4)  under  the  auspices  of  EUCLID 
(European  Cooperation  for  the  Long  term  In  Defence). 
The  timeframe  for  the  study  assumed  applications  in 
the  period  2005- 10  (at  least  for  retrofit  -  though  road 
maps  for  a  new  fast  jet  suggest  c.2015).  Significant 
features  of  the  resulting  General  System  Architecture 
include  a  matrix  switch  network  (MSN)  (similar  in 
principle  to  that  desanbed  in  the  paper  by  Anderson  and 
Stevens  in  Session  I)  and  modular  integrated  digital 
processing  blocks  which  include  high  bandwidth  digital 
signal  processing.  The  implications  of  the  latter,  for  RF 
sensors  in  particular,  is  important  in  that  it  shifts 
upstream  the  interface  between  sensors  and  the  general- 
purpose  configurable  processing  system. 

The  final  paper  of  the  session  placed  the  earlier  two 
papers  usefully  in  context,  showing  the  relevance  of 
those  concepts  for  modernising  existing  mission 
systems,  as  well  as  pointing  the  way  towards  future 
cost-effective  avionics.  The  paper,  “When  do  Advanced 
Avionics  Architectures  Make  Sense  for  Upgrading 
Aging  Aircraft?”,  by  Kreuger  and  Venner  of  Wright 
Patterson  USAFB,  was  presented  by  Sqdn  Ldr  Robert 
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Venner,  RAF.  The  authors  provided  a  valuable  user 
perspective,  arguing  that  by  replacing  ageing  federated 
avionics  systems  on  older  aircraft  with  integrated 
modular  avionics  (IMA)  many  of  the  problems  due  to 
the  huge  variety  of  components  in  existing  federated 
avionics  systems  could  be  overcome.  As  an  example  of 
the  scale  of  the  problem,  the  USAF  support  some  83 
types  of  aircraft  with  more  than  1,000  different  avionics 
systems,  employing  5,000  line  replaceable  units  and 
70,000  shop  replaceable  units.  They  anticipated  that 
IMA  would  yield  major  improvements  in  spare  parts 
obsolescence,  reliability  and  upgrading,  whilst 
providing  growth  capacity  and  enhanced  performance. 
Speculating  on  the  technology  needed  to  implement 
IMA,  they  indicated  several  critical  areas  including,  in 
addition  to  the  software  and  backplane  issues  covered 
in  the  symposium,  the  equally  important  areas  of 
packaging  and  cooling. 

SESSION  III  A:  ARCHITECTURAL  CONCEPTS 

The  first  paper  of  the  session,  “The  Future  of 
Avionics  Architectures”  by  Reed  Morgan  of  Wright- 
Patterson  AFB,  provided  a  general  survey  of  technology 
trends  and  future  projections.  He  illustrated  the  progress 
from  independent  single-function  electronics  of  the 
1940s-50s,  through  federated  systems  of  the  1960s-70s 
with  multi-function  displays  and  controls,  and 
integrated  avionics  systems  of  the  198()s-90s  employing 
common  integrated  processors,  towards  advanced 
integrated  avionics,  post- 2000,  with  ASDN  switching  of 
sensor  outputs  to  shared  “supercomputer”  digital  signal 
and  data  processing.  His  projection  for  future 
architectures  envisages  integrated  RF  sensor  systems 
and  integrated  EO  systems,  shared  apertures/antennae, 
and  optical  heterodyne  receivers,  feeding  a  unified 
digital  avionics  network  with  a  COTS-based  common 
integrated  processor,  via  optical  switches  and  shared 
digital  IF.  His  projection  depends  on  the  development 
of  new  photonic  building  blocks,  digital  signal  and  data 
distribution  across  backplanes  and  changes  (greater 
avionics  industry  involvement?)  in  the  COTS  market 
place. 

In  the  discussion  that  followed,  the  author  replied  to  a 
question  on  the  future  scale  of  software  growth  by 
agreeing  that,  on  present  trends,  it  was  becoming 
unsustainable  without  some  breakthrough  in  software 
generation  (the  F-22  software  has  been  measured  in 
tens  of  millions  of  lines  of  code). 

The  main  concern  of  the  next  paper.  “Technology 
Transparency  in  Future  Modular  Avionics  Systems”,  by 
Edwards,  (British  Aerospace,  UK)  and  Connan 
(Dassault  Aviation.  FR)  was  with  the  problem  of 
obsolescence  caused  by  the  rapidly-evolving  tech¬ 
nology  employed  in  IMA.  The  paper,  presented  by  Ross 
Edwards,  suggested  that  greater  transparency,  as  a  key 
architecture  feature  for  specifications  and  system 
design,  would  help  mitigate  the  problems.  It  requires 
open  IMA  standards,  endorsed  and  supported  by 
industry  and  governments;  whilst  the  market  also  needs 


to  be  led  in  the  right  direction  by  standardization 
programmes  such  as  AS  A  AC  (Allied  Standard  Avionics 
Architecture  Council).  Mr  Edwards,  in  answer  to  a 
question,  agreed  there  was  no  non-avionics  commercial 
electronics  involvement  in  ASAAC  at  present,  but 
noted  that  many  of  the  same  people  were  involved  in 
both  militate  and  commercial  standards  and  there  was 
awareness  of  the  market  potential  of  leading  military 
standards. 

SESSION  III  B:  ARCHITECTURAL  APPLICAT¬ 
IONS 

The  first  paper  of  this  session,  “Integrated  Modular 
Avionics  Architecture  Concepts  Demonstration,”  by 
Potthaus,  BWB,  GE  and  Klockner.  Sprang  and  White, 
ESG,  GE,  was  presented  by  Gordon  White.  The 
demonstration  programme  embraces  key  elements  of  an 
IMA  concept  (related  to  the  ASAAC  activities  refen'ed 
to  in  other  papers,  such  as  that  described  by  Marchetti 
in  Session  11)  including  the  communication  network 
and  the  software  architecture.  He  described  a 
functioning  platfonn  which  has  been  used  to 
investigate,  demonstrate  and  validate  the  comm¬ 
unication  network  concept  (implemented  in  the  first 
instance,  for  purely  concept  demonstration  purposes,  as 
a  4x4  matrix  switched  network  based  on  commercial 
off-the-shelf  components).  The  software  architecture 
demonstration  includes  fault  management  aspects. 
Future  developments  are  intended  to  extend  the 
software  architecture  and  the  communication  network, 
including  the  eventual  application  of  an  optical  switch 
matrix.  In  answer  to  a  question  on  processing  loads,  he 
said  that  benchmarking  was  only  just  beginning  but  the 
programme  was  expected  to  provide  valuable 
confirmation  that  the  overheads  associated  with  the 
network  implementation,  interface  configuration,  etc. 
would  be  acceptable  for  future  applications. 

In  the  paper  that  followed,  “An  Enhanced  Modular 
Avionics  Architecture  for  Military  C"*I”.  by  R  H 
MacDonald  of  the  Norwegian  Defence  Research 
Establishment,  the  author  started  with  the  comment  that 
COTS  was  particularly  important  for  smaller  countries. 
It  was  the  inspiration  for  the  new  design  philosophies 
which  focused  -  as  in  other  papers  -  on  open  systems 
architectures,  new  communications  technology,  and  the 
re-use  of  applications  software.  His  analysis  of  costs/ 
benefits  was  illustrated  by  a  comparison  of  existing  and 
future  communication  standards,  from  Ethernet, 
through  FDDl  and  ATM  to  SCI,  in  which,  for  example, 
he  showed  a  near-tenfold  progressive  improvement  in 
latency  of  information.  He  also  stressed  the  importance, 
when  applying  the  COTS  philosophy,  of  open  standards 
and  continuous  upgrading,  to  help  avoid  the  severe 
problems  of  obsolete  and  unsupported  commercial 
standards. 

The  paper  on  the  “Experimental  Analysis  of  the 
Anomalies  in  the  Structure  of  Radomes  on  their 
Performance”,  by  Qelikel  (Turkish  Air  Force)  and 
Goriir  (Nigde  University),  TU,  though  not  a  main- 
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Stream  Symposium  topic,  was  a  useful  reminder  of  the 
problems  and  limitations  of  real  sensors.  The  paper, 
presented  by  Sadik  (^elikel,  described  the  experimental 
results  of  fitting  Mica  plates  at  various  locations  on  a 
full-size  radome  and  measuring  the  resulting  trans¬ 
mission  and  boresight  errors.  Development  of  the  test 
facility  and  the  test  results  have  provided  insights  into 
the  effect  of  radome  imperfections  which  can  provide  a 
guide  for  repair  and  maintenance. 

The  next  paper,  by  Rico  and  Gallego  of  the  National 
Aerospace  Research  Establishment.  SP,  focused  on  a 
specific  project.  “CAPRICORNIO  Launcher:  an 
Approach  to  a  Modular  and  Low  Cost  Design”  was  an 
interesting  example  of  some  of  the  issues  involved  in 
practical  software  development  for  embedded 
computers.  The  objective  of  the  CAPRICORNIO 
programme  is  to  provide  a  capability  for  launch  of 
small  satellites  into  low  orbits.  The  paper  described  the 
on-board  guidance  and  control  computer  (which  uses 
two  commercial  boards  based  on  standard  32  bit 
processors  connected  by  a  VME  bus,  and  an  RS422 
interface  with  the  thrust  vector  and  aileron  actuator 
systems),  plus  the  ground  control  system.  They  are 
being  developed  in  the  first  instance  for  the  ARGO  test 
vehicle  which  is  being  used  to  demonstrate  the  systems 
prior  to  the  full-scale  CAPRICORNIO  launcher. 
Software  development  has  emphasised  low  cost, 
modularity  and  flexibility  to  facilitate  migration  from 
ARGO  to  CAPRICORNIO.  The  software  requirements 
were  developed  using  structured  analysis  techniques 
and  implemented  in  Ada.  The  software  development  en¬ 
vironment  embraces  a  variety  of  tools,  including  the 
LabVIEW  graphics  tool  which  has  been  used  for  the 
GCS  software,  a  prototype  of  which  has  been  tested  by 
the  user. 

The  main  concern  of  the  final  paper  in  this  session, 
“Signature  Avionics  -  Signature  Optimised  Operating 
of  a  Stealth  Aircraft”  by  Hurst,  Knappe  and 
Benninghofen  of  Daimler  Benz  Aerospace,  GE.  was 
with  avionics  that  avoid  compromising  the  signature  of 
stealth  aircraft,  or  which  take  advantage  of  their  stealth 
characteristics,  or  which  coordinate  stealth  design  and 
avionics  functions.  The  authors  described  the  Dasa 
Software  Technology  Environment  for  rapid 
prototyping  and  initial  testing,  followed  by  integration 
in  their  Avionics  Testbed  which  provides  a  cockpit 
simulation  with  external  scene  representation.  An 
example  of  a  practical  application  was  presented  in  the 
concept  of  “fly  by  signature”  which  aims  to  minimise 
exposure  of  stealth  aircraft  to  air  defence  systems  by 
flight  path  optimisation,  taking  into  account 
geographical  threat  models  and  the  aircraft's  own 
signature.  In  the  discussion  that  followed,  the  authors 
indicated  the  aim  was  to  provide  a  real-time  capability 
which  would  have  practical  applications  in  mission 
planning  and  execution. 

This  session  was  noteworthy  for  the  range  of 
aerospace  applications  covered,  including  software 
development  for  satellite  launcher  guidance  and  control. 


SESSION  IV  A:  ADVANCED  MISSION  SYSTEMS 
TECHNOLOGIES 

This  session  comprised  four  papers,  two  of  which 
were  concerned  with  a  critical  element  of  advanced 
architectures  -  network  switching. 

The  first  paper,  “A  Multiservice  Switch  for  Advanced 
Avionics  Data  Networks”,  was  by  Rosen,  Turner, 
Gershman  and  Birmingham  of  the  US  Naval  Air 
Warfare  Center,  and  Phipps  and  George  of  FAMU-FSU 
College  of  Engineering,  Tallahassee.  US.  It  was 
presented  by  Vladimir  Gershman.  He  first  outlined  the 
requirement  for  a  unified  data  network  to  replace  a 
variety  of  existing  interconnects  and  to  include  sensor/ 
video.  In  addition  to  high  data  transfer  rates,  fault 
tolerance,  COTS  utilization,  low  power,  low  cost  and 
low  weight,  the  unified  network  must  be  capable  of 
adapting  to  the  conflicting  capabilities  of  the  individual 
networks  it  replaces.  The  IEEE  1596-1992  SCI 
(Scalable  Coherent  Interface)  standard  has  provided  the 
basis  for  the  MSS  and  a  prototype  produced,  based  on 
the  commercial  Dolphin  LC-1  link  controller  chip.  It 
has  successfully  demonstrated  its  capacity  for  handling 
varying  types  of  interconnect  requirements,  such  as 
streaming  data  at  one  extreme  and  low-latency  burst 
messages  at  the  other.  It  has  also  proven  equal  or 
superior  in  throughput  to  individual  conventional 
network  topologies. 

The  next  paper,  presented  by  David  Aupers  was  also 
concerned  with  high  speed  interconnection  systems  for 
modular  avionics.  “Simulation  of  a  Cell  Switched 
Network  for  the  Control  of  a  Switch  Matrix  in  a  High- 
Speed  Avionics  Network”,  by  Aupers,  Heerink  and 
Wellink  of  NLR,  NL,  described  research  being  carried 
out  as  part  of  a  EUCLID  research  and  technology 
prograntme  (RTF  4.1  -  as  also  were  papers  in  Sessions 
1  and  11).  The  research  programme  has  modelled  and 
simulated  an  optical  switch  matrix  for  circuit-switched 
point-to-point  connections,  with  a  Cell  Switched 
Asynchronous  transfer  mode  (ATM)  network  to  control 
the  switch  and  provide  transfer  of  lower-rate  data,  files 
and  status  messages.  ATM  (used  also  in  the  B-ISDN 
successor  to  the  ISDN  standard)  was  selected  after 
comparison  with  1553,  FDDl  and  SCI  on  the  basis  of 
technical  suitability,  and  the  commercial  and  academic 
availability  of  models  and  technology.  The  results  have 
provided  useful  indications  for  practical  implement¬ 
ation  of  the  system. 

The  next  paper,  “Multifunction  Radio  Systems  for 
Multinational  Systems”  by  G  Mey  (Ministry  of  Def¬ 
ence)  and  P  H  Reitburger  (Rhode  &  Schwarz),  GE,  was 
presented  by  Dr  Peter  Reitburger.  The  paper  described 
the  requirements,  design  principles  and  architecture  for 
multi-function  radios  capable  of  handling  a  diversity  of 
standards.  The  architecture  embraces  five  modules 
(antenna  system,  receiver/transmitter,  presignal 
processing,  data  processing,  and  man-machine 
interface)  each  capable  of  a  variety  of  modes  and 
functions.  The  advantages  of  such  equipment  were 
shown  in  an  example  of  an  aircraft  mission,  in  which 
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the  equipment  could  function  with  different  RF 
waveforms  (HF,  VHF,  UHF.  JTIDS,  MLS/DME-P, 
Radar  Altimetry,  GPS,  NIS,  and  SATCOM)  that  at 
present  require  individual  receivers/transmitters.  The 
authors  stressed  the  advantages  for  multinational  NATO 
operations. 

The  final  paper  in  this  session  addressed  many  of  the 
same  issues  as  the  paper  by  Williams  and  Collier  in 
Session  I,  in  particular  the  use  of  external  real-time 
infonnation  to  enhance  on-board  avionics  performance. 
Richard  Kirchner  presented  the  paper  on  “Rapid 
Targeting  and  Real-Time  Response”  by  Searle, 
Kirchner,  Fincher  and  Armogida  of  the  US  Naval  Air 
Warfare  Center,  China  Lake.  The  paper’s  sub-title,  “The 
Critical  Links  for  Effective  Use  of  Combined 
Intelligence  Products  In  Combat  Operations,”  gives  an 
idea  of  the  main  thrust  of  the  paper,  which  follows 
demonstrations  by  the  US  Navy  (Forward  Hunter)  and 
Air  Force  (Goldpan)  of  “Real-Time  into  the  Cockpit/ 
Offboard  Targeting”  (RTIC/OT).  This  operational 
concept  aims  to  improve  mission  planning  time  and  the 
response  to  rapidly  changing  battlefield  conditions,  by 
providing  real-time  inputs  to  aircrew  from  a  variety  of 
sources.  These  would  include  for  example,  UAVs, 
theater  reconnaissance  aircraft,  satellites,  etc.,  directly 
transmitted  -  or  relayed  -  to  strike  aircraft.  An 
important  element  in  the  RTIC/OT  concept  is  provision 
of  imagery  to  the  cockpit  to  assist  in  target  acquisition, 
as  shown  in  the  joint  exercise.  Arid  Hunter.  This 
exercise  demonstrated  that  major  improvements  could 
be  achieved  when  imagery  was  input  to  the  cockpit  and 
combined  with  the  use  of  GPS,  compared  to  using 
either  GPS  alone  or  killbox  coordinates.  The  RTIC/OT 
concept  is  being  developed  through  a  number  of  USN 
and  USAF  demonstration  programmes.  The  question 
and  answer  session  at  the  end  of  this  paper  raised 
several  interesting  points,  particularly  in  regard  to 
imagery  aids  for  target  acquisition.  The  author  agreed 
that  different  conclusions  could  be  drawn  in  the  case  of 
autonomous  weapons  where  the  target  coordinates  are 
known  with  high  accuracy,  but  was  not  convinced  by  a 
suggestion  that  on-board  platform  sensors  correlated 
with  pre-stored  target  imagery  might  do  the  whole  job 
equally  well  in  manned  aircraft,  because  of  the 
limitations  in  quality  or  format  of  on-board  sensor 
imagery. 

SESSION  IV  B:  PROCESSOR  TECHNOLOGY 

This  session  contained  four  papers  of  widely  varying 
subject  matter.  The  first  paper,  “Integrated  Processing”, 
by  Farmer,  Robinson  and  Trujillo  of  Hughes  Aircraft 
Company,  US,  and  presented  by  Edward  Trujillo, 
started  with  an  overview  of  the  requirements  and  aims 
for  modular  integrated  avionics,  covering  much  of  the 
same  ground  as  earlier  papers  (integration,  modularity, 
commonality,  open  systems,  COTS).  The  author  went 
on  to  describe  the  evolution  of  avionics  standards  and 
supporting  technology  via  second  generation  DAIS, 
third  generation  Pave  Pillar  (represented  by  the 


Common  Integrated  Processor  for  the  F-22  Advanced 
Tactical  Fighter  avionics),  to  fourth  generation  Pave 
Pace.  The  written  paper  describes  the  Hughes  Modular 
Processor  for  the  F-22,  based  on  open  standards  and 
commercial  components  (e.g.  SAE  4710  PI  Bus  and 
Intel  i960  RISC  processor)  and  a  single  chip  upgrade 
for  an  existing  multi-chip  processor.  An  important 
conclusion  of  the  paper,  as  presented,  was  the 
recognition  that  to  extract  the  maximum  value  from 
COTS  it  is  necessary  to  consider  carefully  what 
additional  purpose-designed  elements  need  to  be 
developed. 

“A  Modular  Scalable  Signal  Processor  Architecture 
for  Radar  and  EW  Applications”,  by  Keller,  Rabel,  and 
Schmitt  of  Daimler  Benz  Aerospace,  GE,  was  presented 
by  R  Rabel.  The  paper  described  the  Advanced 
Programmable  Signal  Processor  (APSP)  developed  by 
Dasa  in  support  of  ASAAC/Euclid,  as  part  of  a  strategy 
for  achieving  proven  high  performance  systems  based 
on  off-the-shelf  technology.  The  APSP  consists  of 
expandable  arrays  of  programmable  modules  (based  on 
clusters  of  Texas  Instruments  TMS320C3x  processors) 
and  semi-programmable  modules  (containing  dedicated 
processing  hardware  such  as  EFT  processors),  con¬ 
nected  by  a  VME  bus  and  associated  modules,  and  a 
Data  Transfer  Network.  The  paper  describes  the 
operating  system,  APOS,  and  applications  of  APSP, 
including  a  real-time  SAR  processor  with  eight  Doppler 
processors.  In  his  answers  to  questions,  the  author  made 
it  clear  that  the  architecture  descTibed  is  only  one  of  the 
ASAAC  candidates.  He  also  said  that  the  APOS  level 
allows  for  upgrades  and  -  as  stressed  in  the  paper  by 
Edwards  and  Connan  in  Session  lllA  -  a  high  degree  of 
transparency. 

The  next  paper,  “A  Survey  of  Advanced  Information 
Processing  (AlP)  Technology  Areas  for  Crew  Assistant 
System  Development”,  by  Kuru  and  Akin  of  Bogaziqi 
University,  Istanbul,  TU,  described  work  on  a  part  of 
the  EUCLID  RTP  6.5  Crew  Assistant  project,  in 
collaboration  with  Alenia,  Dasa  and  NLR.  The  paper, 
presented  by  H  L  Akin,  covered  the  methodology  of  the 
survey,  including  choice  of  evaluation  criteria 
(functionality,  reliability,  perfonnance,  modularity, 
integration  with  other  technologies,  engineering 
methodology,  maturity/next  generation,  and  avail¬ 
ability)  and  the  results  of  the  survey,  covering  software 
engineering  methodologies;  verification,  validation  and 
certification;  knowledge-based  systems;  distributed 
artificial  intelligence;  learning  systems;  planning; 
model-based  reasoning;  case-based  reasoning;  object- 
oriented  databases;  and  finally  a  summary  of  AIP 
technologies  used  in  existing  programmes.  From  their 
comprehensive  survey,  they  concluded  that  readily 
available,  mature  AIP  technologies  had  been  identified 
that  can  provide  the  required  CA  capability. 

The  main  subject  of  the  last  paper  in  this  session, 
“New  Sources  of  Geographical  Data  for  Automatic 
Identification  Application”  by  Peufeilhoux,  Cazeneuve 
and  Hervy,  of  Thomson-CSF,  FR,  was  the  combined 
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use  of  various  geographical  data.  The  paper,  presented 
by  Philippe  Hervy,  addressed  the  problems  of  terrain 
identification  and  recognition  in  relation  to  cruise 
missiles  and  long  range  aircraft  operations.  The  sources 
of  data  discussed  included  1/15,000  scale  national 
topographical  maps,  satellite  images,  and  global  digital 
data  bases  such  as  the  1/100,000  scale  DCW  (Digital 
Chart  of  the  World),  and  1/200,000  scale  VMAP 
(Vector  Map).  An  example  was  given  of  air-to-suiface 
target  identification  utilizing  geographical  data  with  a 
purpose-developed  algorithm.  The  paper,  though  not 
strictly  aligned  with  the  session's  title  of  “Processor 
Technology”,  was  interesting  as  an  example  of  data 
fusion  to  maximise  the  utility  of  alternative  information 
sources. 

SESSION  V:  INFORMATION  PROCESSING  APP¬ 
LICATIONS 

This  was  the  longest  session  of  the  symposium,  with 
papers  focused  mainly  on  avionics  applications  to 
mission  planning,  management  and  execution. 

The  first  paper,  “Mission  Management  System 
Design”,  by  Sassus,  Bonhoure  and  Marito  of 
SEXTANT  Avionique,  FR,  was  presented  by  Fabienne 
Bonhoure.  The  objective  of  the  work  described  was  to 
improve  mission  effectiveness  in  a  high  workload 
environment  by  providing  active  en-route  planning  and 
decision-making  aids  with,  for  example,  automatic 
prompts  as  necessitated  by  the  tactical  situation  and 
mission  deviations.  The  paper,  subtitled  “A  Technical 
and  Methodological  Approach”,  first  defined  the 
mission  management  function,  followed  by  descriptions 
of  the  software  architecture  and  development 
methodology,  and  implementation  in  a  mission  sim¬ 
ulator.  The  programme  is  to  be  developed  to  include  a 
wider  range  of  missions  and  theatres,  and  on-board 
implementation  aspects.  In  reply  to  questions  regarding 
pilots’  willingness  to  use  automated  on-board  mission 
management  and  on  the  realism  of  the  simulation,  the 
author  emphasised  the  element  of  choice  in  the 
presentiition  and  use  of  pilot  prompts,  and  the  immense 
value  of  pilots’  participation  in  the  programme. 

By  contrast,  the  second  paper,  “Mission  Planning 
Systems:  Cubic  Multipliers”,  by  de  Moel  and  Heerema 
of  NLR,  NL,  was  concerned  with  the  multiplier  effects 
of  improving  the  ground  element  of  mission  planning. 
The  paper,  presented  by  R  P  de  Moel.  considered  three 
aspects;  firstly,  the  quality  of  information  -  in 
particular,  geographical  data  -  for  mission  planning  and 
its  effect  on  mission  execution;  secondly,  the 
importance  of  unifonn  training  and  of  training 
exercises;  and  thirdly,  the  technology  of  training  and 
simulation.  The  paper  focused  on  geographical  data 
sources  with  the  emphasis  on  Nato  Standard 
Agreements  (STAN AGs)  and  on  the  evolution  of  NCR's 
mission  planning  workstations  which  started  in  1979 
and  led  to  the  semi-operational  CAMPAL  (Computer 
Aided  Mission  Preparation  at  Airbase  Level) 
workstation  of  1991  to  1994,  with  3D  colour  graphics. 


high  resolution  display  and  colour  hard  copy  unit.  The 
operational  mission  support  system,  currently  being 
developed,  is  known  as  PANDORA  (Planning  of 
Aircraft  Navigation  for  Defensive,  Offensive  and 
Reconnaissance  Airtasks).  A  question  regarding  the 
comprehensiveness  of  geographical  data  and  use  of 
satellite  imagei^  was  answered  with  an  acknowledge¬ 
ment  that  development  was  an  ongoing  process  and 
Nato  image  standards  would  be  incorporated  as  they 
appeared;  and  in  answer  to  a  further  question  on  in¬ 
flight  re-planning,  the  author  referred  to  future 
developments  with  a  timely  reminder  that  it  was  first 
necessary  to  solve  today's  problems. 

The  English  title  of  the  next  paper,  as  given  in  the 
programme,  “Mission  Recording  and  Restitution”, 
translated  from  the  original  French,  “Systeme 
d'enregistrement  et  restitution  de  Mission”,  would  have 
been  better  translated  as  mixsion  recording  and 
playback  -  playback  being  the  main  purpose  of  the 
system.  The  paper,  by  F  X  Parisot  of  SAGEM,  FR, 
describes  the  overall  functional  scheme,  comprising  the 
on-board  interface  box  BISE  (BoTtier  d'lnterface 
Systeme  -  Emports)  which  takes  inputs  from  the 
mission  computer  (including  mission  planning  input 
data)  and  sensors,  plus  video  recording  and  cockpit 
displays.  Among  other  functions,  the  BISE  provides 
time  multiplexing  of  video  inputs  and  generation  of 
time  markers  for  hannonising  digital  data.  The  video 
recorder  data  is  combined  with  mission  computer  data 
in  the  playback  system  for  post-mission  analysis.  The 
author  also  expanded  on  the  written  paper  with  a 
description  of  the  further  development  of  on-board  real¬ 
time  replay  as  a  mission  aid,  involving  additional 
equipment  for  video  compression/decompression  and  a 
short  term  drum  recorder,  the  equipment  weighing  an 
additional  one  kilogramme  with  a  volume  of  one  litre. 
Further  development  is  aimed  at  completely  digital 
recording. 

The  paper  on  “A  Generic  Architecture  for  Crew 
Assistant  Systems”  by  IJrlings  and  Zuidgeest  of  NLR, 
NL,  was  presented  by  Pierre  Urlings.  In  it,  he  outlined 
the  background  and  requirements  for  crew  assistants, 
emphasising  the  enhancement  of  crews’  system  and 
situational  awareness,  and  some  results  of  work  carried 
out  as  part  of  EUCLID  RTP  6.5  -  a  multi-national 
effort  directed  towards  CA  concept  demonstration.  The 
functional  architecture  is  based  on  a  division  into  CTew 
assistant  functions  that  con'espond  to  crew  functions, 
either  uniquely,  or  grouped  where  appropriate.  Each  CA 
function  follows  the  same  basic  data  flow  of  collection, 
assessment,  decision  and  presentation,  with  shared 
management  of  data  input,  control,  coordination  and 
presentation  to  displays  and  controls.  The  author 
described  the  CA  concept  as  a  rich  area  for  AIP 
(advanced  information  processing),  citing  the  two  main 
approaches  to  DPS  (distributed  problem  solving)  - 
distributed  knowledge  sources  (blackboard  system)  and 
multi-agent  systems  -  as  indicative  of  the  technology 
and  its  maturity  for  next  generation  crew  assistant 
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applications.  Questions  to  the  author  were  concerned 
with  development  and  certification,  issues  that  were 
addressed  in  the  related  paper  by  Kuru  and  Akin  in 
Session  IVB,  and  the  topic  of  crew  overruling  and  its 
implementation,  whose  extreme  importance  was  well 
recognised  by  the  authors. 

The  following  paper  was  also  devoted  to  the  topic  of 
crew  assistants.  “Perspectives  of  Crew  Assistance  in 
Military  Aircraft  through  Visualizing,  Planning  and 
Decision  Aiding  Functions”  by  Schulte  and  Kldckner  of 
ESG,  GE,  was  presented  by  Dr  Axel  Schulte  who 
described  the  GAMA  (Crew  Assistant  Military  Aircraft) 
system.  This  knowledge-based  expert  system,  develop¬ 
ed  in  cooperation  with  the  University  of  the  German 
Armed  Forces,  Dasa,  and  DLR,  is  intended  to  improve 
crew  situational  awareness  and  assist  in-flight  planning 
and  decision  making.  After  describing  CAMA’s 
background  philosophy  and  architecture  (including 
situation  information  acquisition,  interpretation  and 
assessment,  planning  and  crew  interface  functions),  the 
paper  went  on  to  describe  the  parallel  development  of 
the  software  prototype  Tactical  Situation  System.  It 
consists  of  four  main  modules:  Interpreter,  Low- 
Altitude  Flight  Planner,  Display,  and  Enhanced  Flight 
Guidance  Display  (which  provides  computer  generated 
3-D  imagery  superimposed  on  a  sensor  output  display). 
Demonstration  and  evaluation  has  included  flight 
demonstration  of  the  Enhanced  Flight  Guidance 
Display  which  -  in  answer  to  a  question  -  Dr  Schulte 
said  had  been  useful  in  showing  the  difficulties  of 
combining  synthetic  and  sensor  images.* 

The  paper  “Sensor  Fusion  for  Modern  Fighter 
Aircraft”,  by  Taubenburger  and  Ziegler  of  Dasa,  GE, 
presented  by  Joseph  Ziegler,  used  a  beyond-visual- 
range  scenario  for  illustration.  Comparison  of  onboard 
radar,  infrared  and  ESM  sensor  coverage  (including  on¬ 
board  weapons’  sensors)  pointed  up  their  advantages 
and  disadvantages  in  terms  of  range  and  resolution  and 
the  potential  for  increased  coverage  by  multi-aircraft 
cooperative  sensor  utilization  via  data  links.  The  sensor 
fusion  functions  include  kinematic  correlation,  identity 
fusion,  threat  assessment  and  sensor  management, 
while  implementation  involves  trade-offs  between 
hardware  availability,  track  continuity  and  accuracy, 
data  bus  loads,  and  independence  of  input  data.  The 
process  sequence  operates  on  input  data  at  the  sensor/ 
data  source  level  with  associative  and  cost  matrix 
analysis  before  fusion  by  Kalman  filter  and  utilization. 
A  typical  architecture  showed  a  data  bus  link  between 
the  sensor  management  and  fusion  system  and 
independent  input/outputs  to  sensors,  fire  control,  and 
pilot  controls/displays,  retaining  the  capability  for 
utilizing  the  output  of  the  sensors  directly  and 


*  Footnote:  The  Symposium  Chairman,  Mr  Larry  Ott 
mentioned  plaits  for  an  MSP  working  group  on 
distributed  command  and  control  for  coordinated  strike 
packages,  for  which  this  and  other  symposium  papers 
were  relevant. 


individually,  or  through  the  sensor  fusion  system.  The 
discussion  that  followed  highlighted  the  importance  of 
improving  quality  -  and  presentation  -  of  threat 
information  to  the  pilot. 

SESSION  VI:  ROLE  OF  COMMERCIAL  COMP¬ 
ONENTS 

This  final  session  was  devoted  entirely  to  papers  on 
the  use  of  COTS  (Commercial  Off-The-Shelf)  comp¬ 
onents  and  related  topics,  a  subject  which  had  cropped 
up  several  times  in  other  papers.  The  emphasis  on 
COTS  was  a  recognition  that,  at  a  time  of  diminishing 
defence  expenditure,  advanced  avionics  systems  can 
only  be  made  affordable  by  making  use  of  the  huge 
investments  in  commercial  information  and  electronics 
technologies,  and  where  possible,  influencing  its 
direction. 

The  first  paper  of  the  session,  “Impact  of  COTS  on 
Military  Avionics  Architectures”,  by  Carbonell  and 
Ostgaard  of  the  Wright  Laboratory,  Wright-Patterson 
AFB,  US,  provided  an  overview  from  a  User 
perspective.  The  paper  was  presented  by  Juan 
Carbonell,  who  started  with  a  reminder  of  the  1994 
“Best  Commercial  Practices”  initiative  of  the  US 
Secretary  of  Defense,  William  Perry,  which  was 
followed  by  a  Wright  Laboratory  study  in  1995  of  the 
implications  of  using  COTS  hardware  and  software  in 
avionics.  He  made  the  observation  -  unsurprising, 
though  noteworthy  -  that  “eliminating  unnecessary 
constraints”  on  contractors  offers  major  cost  saving 
potential;  particularly  for  necessarily  non-commercial 
items  such  as  sensors,  which  make  up  over  half  of 
avionics  costs  compared  to  the  digital  “core”  area 
which  accounts  for  only  about  a  quarter.  The  main 
issues  addressed  in  the  paper  included:  packaging  and 
the  problem  of  military  environments;  obsolescence 
and  its  management;  software,  with  particular  reference 
to  commercial  standards  and  the  implications  of  US 
DoD  legal  requirement  to  use  only  Ada  as  a  high  level 
language;  testability  and  COTS  inadequacies; 
throwaway  modules  as  an  economical  alternative  to 
diagnostic  test  and  repair;  and  finally,  system 
implications,  with  particular  reference  to  open 
standards.  The  paper  concluded  by  stressing  the  need 
for  a  flexible,  systems  approach  to  COTS  and 
acknowledging  the  need  to  avoid  overspecification  and 
universal  imposition  of  MIL-STD  processes  which,  in 
the  past,  have  militated  against  affordability. 

The  next  paper,  by  Grasshof  (Daimler  Benz  Aero¬ 
space)  and  Foerster  (Daimler  Benz  Inter  Services),  GE, 
was  concerned  with  a  specific  programme,  related  to 
the  EUCLID  and  ASAAC  modular  avionics  prog¬ 
rammes  referred  to  in  earlier  papers.  Matthius  Grasshof 
presented  the  paper,  “An  Approach  Towards  Integration 
of  a  Modular  Core  Avionics  System  Kernel”,  which 
described  SYMS  (SYstems  Management  Software) 
designed  specifically  for  modular  avionics  application. 
The  need  for  this  special  (Ada)  software  development, 
following  an  earlier  experimental  modular  avionics 
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system  using  VMEbus  hardware  and  a  commercially 
available  operating  system,  indicated  some  of  the 
limitations  of  commercial  systems  for  advanced 
avionics  systems.  SYMS  has  experimentally  demon¬ 
strated  the  flexibility  and  reconfigurability  required  and 
its  facility  for  integrating  COTS  or  ROTS  (Ruggedized 
Off  The  ShelO  systems  and  components.  In  reply  to 
questions  regarding  additional  software  overheads  and 
perfonnance,  the  author  refen'ed  to  the  next  steps  of  the 
ongoing  programme  which  will  include  further 
demonstration  of  real  applications. 

The  next  paper,  “Low  Level  Flight  Capability  of  a 
Future  Military  Transport  Aircraft  Based  on  Com¬ 
mercial  Avionics”  was  by  Kricke  and  Schafer  of 
Daimler  Benz  Aerospace  Airbus,  GE.  It  was  presented 
by  Dr  Dieter  Kricke,  who  began  with  a  summai7  of 
flight  guidance  systems  for  commercial  aircraft  on 
which  the  military  transport  would  be  based.  The  basic 
elements  of  fly-by-wire,  autoflight  control,  and  flight 
management  were  described,  followed  by  special 
military  mission  needs  such  as  low-level  segments  and 
subsequent  board-autonomous  landings  (that  is,  self- 
contained  and  unsupported  by  ground  control  systems), 
plus  deviations  from  pre-planned  routes  in  response  to 
threats.  Additional  flight  management  functions  include 
on-board  flight  profile  re-planning,  accomplished  with 
special  controls  and  displays  (particularly  a  touch 
screen  LCD  for  inputting  way  point  data,  and  automatic 
4-D  flight  path  generation),  special  flight  plan 
execution  of  landing  windows  etc.,  and  low  level  flight 
guidance  infonnation  by  head  up  display.  The 
discussion  that  followed  centred  on  the  special  needs  of 
military  transports,  such  as  the  demands  on  flight 
control  and  propulsion  response  from  dropping  heavy 
loads. 

Marlow  Flenne,  of  Sverdrup  Technology,  presented 
the  final  paper  of  the  symposium  -  “Selecting  a 
Software  Developer  in  a  Specification  Free  Acquisition 
Environment”  by  Henne  and  Kandel  (University  of 
South  Florida),  US.  It  directly  addressed  an  important 
issue  raised  in  the  first  paper  of  this  session,  that  of 
managing  programmes  that  are  no  longer  subject  to 
detailed  government  specification  of  the  development 
processes.  The  USAF's  Aeronautical  Systems  Center 
(ASC)  has  introduced  Software  Development  Cap¬ 
ability  Evaluation  (SDCE)  as  a  formal  approach  to 
contractor  selection.  It  recognises  that  past  perfonnance 
is  not  always  a  reliable  guide  and  emphasises  in-plant 
evaluation,  with  particular  attention  to  selection  of  a 
review  team.  Six  functional  areas  are  considered  in  the 
evaluation:  program  management;  systems  engineering; 
software  engineering;  quality  management  and  product 
control;  organizational  resources  and  program  support; 
and  finally,  program  specific  technologies;  with  further 
subdivision  into  critical  capability  areas.  Although  the 
approach  might  appear  somewhat  bureaucratic,  the 
author  claimed  the  process  had  been  shown  to  be 
effective,  time  efficient,  and  fair.  It  had  also  shown 
itself  useful  as  a  support  tool  during  development,  to 


identify  strengths  and  weaknesses  by  “Red  Team” 
reviews.  The  paper  stimulated  a  good  deal  of 
discussion,  much  of  it  concerned  with  the  wider 
application  of  the  technique  to  other  Services  and 
within  Industry.  In  answer  to  a  question  on  measure¬ 
ment  of  SDCE  effectiveness,  the  author  reiterated  the 
comments  made  in  the  paper  on  the  value  shown  by  25 
in-plant  visits  so  far. 

PANEL  DISCUSSION;  THE  IMPACT  OF  AD¬ 
VANCED  ARCHITECTURES  ON  AFFORD¬ 
ABILITY 

The  Chairman,  Larry  Ott  suggested  by  way  of  intro¬ 
duction  three  discussion  topics  -  architectures, 
information  management,  and  COTS  -  and  ntade  three 
related  observations:  firstly,  that  Military  Users  should 
take  advantage  of  commercial  hardware  and  software  as 
a  key  driver  towards  affordability;  secondly,  that  the 
cost  reductions  from  open  architectures  should  become 
practical  as  the  technologies  of  data/signal  commun¬ 
ications  networks  were  put  in  place;  and  thirdly,  that 
dissemination,  fusion  and  utilization  of  tactical 
information  to  improve  situational  awareness  could 
simplify  sensor  requirements,  though  it  might  require 
more  automation  to  limit  crew  workload  to  acceptable 
levels. 

He  noted  a  great  deal  of  international  recognition  of 
the  issues  involved  -  for  example:  the  introduction  and 
retrofitting  of  open  systems  and  the  achievement  of 
commonality  across  different  aircraft  types;  COTS  in 
relation  to  military  needs,  particularly  in  platfonn 
upgrades;  the  impact  of  open  architectures  on  the 
Defence  Industrial  Base,  such  as  new  ways  of  doing 
business  and  changes  in  the  roles  of  companies;  and  the 
questions  of  data  integrity,  real-time  availability  and 
crew  acceptance  in  implementing  “crew  assistants”. 

Ross  Edwards  warned  against  fixing  too  quickly  on 
any  particular  technology  for  implementing  advanced 
avionics  -  such  as  SCI  for  example  -  which  might  risk 
early  obsolescence.  It  was  not  enough  to  seize  on  a  new 
technology  or  standard  and  produce  a  demonstrator: 
transparent  systems  were  needed  in  order  to  avoid 
ripple  effects  of  a  single  technology  choice  and  to 
provide  the  desired  llexibility  and  adaptability  for 
growth  and  change.  Terry  Domae  added  that  a  simple 
software/hardware  interface  by  itself  was  not  enough: 
COl'S  implies  the  need  to  accept  change  and  plan  for 
limited  life. 

Dieter  Kricke,  offered  a  slightly  different  perspective. 
Experience  in  the  last  fifteen  years  showed  that  early 
technology  decisions  followed  by  system  analysis 
through  two  or  three  layers,  resulted  in  systems  with 
built-in  obsolescence.  He  called  for  a  “paradigm 
change”  to  carry  out  system  analysis  before  hardware 
selection.  The  need  for  new  R&D  approaches  was 
supported  by  Jochen  Potthaus,  who  commented  that  it 
was  no  longer  appropriate  for  international  programmes 
to  be  constructed  around  the  division  of  hardware 
responsibilities.  Experience  had  shown  the  value  of 
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full-blown  simulations  in  advance  of  procurement 
decisions. 

Reed  Morgan  commented  that  discussion  of  avionics 
architectures  focused  too  much  on  data  processing,  and 
he  reminded  the  Symposium  that  most  avionics 
expenditure  was  on  sensors.  There  was  a  need  to  shift 
attention  to  adaptable  digital  signal  processing  -  a  new 
discipline  requiring  a  wider  breadth  of  interest.  Ken 
Helps.  UK  (Chainnan  of  Session  V)  remarked  that  the 
COTS  approach  might  have  a  lot  to  learn  from  the 
automotive  industry,  where  signal  processing  devices 
were  expected  to  sun'ive  8  to  10  years  or  more. 
Similarly,  an  open.  Java-like  software  approach  might 
be  expected  to  provide  much  needed  .system 
transparency. 

The  big  issue  identified  by  C  H  Krueger,  was  the 
inevitable  high  cost  of  on-board  avionics,  whether  in 
procurement  or  support.  He  cited  the  case  of  GPS 
receivers,  available  over  the  counter  commercially  for  a 
few  hundred  dollars  but  costing  half  a  million  dollars 
for  aircraft  installations.  The  best  way  round  the 
problem  of  high  cost  avionics  was  to  “take  it  off  the 
aircraft”  as  far  as  possible  and  instead  use  external  data/ 
infonnation  sources  as  proposed  by  Williams  and 
Collier  (paper  in  Session  1). 

John  Niemela.  US  (Chairman  of  Session  IVA)  raised 
the  question:  what  would  be  the  process  for  re¬ 
qualifying  highly  integrated  avionics  suites,  where  a 
small  change  could  affect  the  whole  system?  Reed 
Morgan  made  the  further  point  that  some  of  the 
implications  of  accepting  de  facto  commercial  stand¬ 
ards  -  such  as  Fiberchannel  which  could  fairly  .soon  be 
.superseded  in  the  market  place  -  were  frightening.  He 
also  argued  the  case  for  field-programmable  gate  amays 
that  would  enable  software  control  drivers  to  be  kept 
separate  from  the  rest  of  the  software  -  a  POSIX-like 
concept  that  is  perhaps  two  or  three  years  away  and 
might  allow  systems  to  “roll  with  the  punches”  of 
COTS  changes.  Ross  Edwards  pointed  out  that  the 
ASAAC  reloadable  protocol  answers  that  particular 
.software  problem,  though  the  problem  of  an  adaptable 
physical  interface  remains. 

The  discussion  of  COTS  utili.sation  was  rounded  off 
by  Ir  Henk  Timmens  (Chainnan  of  Sessions  IIIA  and 
IllB)  who  advised  caution.  The  costs  of  implementing 
COTS  policy,  and  the  possibility  that  incomplete  and 
incoherent  systems  might  result,  may  not  become 
apparent  for  five  or  ten  years. 

The  Round  Table  Discussion  concluded  with  a 
general  expression  of  concern  on  the  ability  of  software 
development  to  keep  up  with  hardware  development, 
presenting  a  severe  bottleneck  on  progress  towards 
advanced  avionics  systems.  It  was  also  acknowledged 
that  the  issues  of  re-useability  and  transportability  had 
not  been  as  fully  addressed  in  the  Symposiuin  as  they 
might  have  been. 


CONCLUDIN(J  REMARKS 

This  successful  symposium  covered  a  lot  of  ground, 
directly  or  indirectly  relevant  to  the  title  and  theme.  If  a 
slight  reservation  may  be  made,  it  is  that  military  needs, 
research  programmes,  applications  and  technology 
were  so  interrelated  in  many  papers  as  to  produce  some 
inevitable  loss  of  coherence  in  the  symposium  as  a 
whole.  For  example,  several  papers  could  just  as  easily 
have  been  assigned  to  other  sessions  as  the  ones  in 
which  they  appeared.  However,  this  did  not  detract 
from  the  overall  value  and  interest  of  the  symposium 
which  covered  the  subject  of  advanced  aerospace 
mission  systems  architectures  in  width  and  depth. 

The  overall  impression  that  emerged  was  of  a  major 
impact  on  future  rnilitaiy  capabilities  that  will  result 
from  developments  taking  place  on  both  sides  of  the 
Atlantic  in  signal  and  data  processing/communications 
and  related  areas  of  advanced  infonnation  technology. 
I’hese  advanced  technologies  hold  out  the  promise  of 
highly  integrated  mission  systems  that  will  be  much 
more  adaptable,  fault  tolerant  and  affordable  than 
present  systems.  The  fact  that  much  of  the  hardware 
and  software  technology  is  commercially  inspired 
makes  the  drive  towards  COTS  utilization  at  once  more 
readily  attainable  and  at  the  same  time  a  source  of 
concern  in  two  respects:  firstly,  the  requirements  for 
advanced  avionics  in  key  areas  remain  in  advance  of 
commercial  developments;  while  paradoxically,  the 
extended  life  span  of  rnilitaiy  systems  can  leave  mature 
systems  with  hardware  and  software  standards  that  may 
be  obsolete  and  no  longer  supported  in  the  market 
place.  Suggestions  for  overcoming  these  concerns 
included  closer  involvement  by  defence  avionics 
companies  with  commercial  electronics  companies 
(with  advantages  to  both  parties)  and  more  frequent 
pre-planned  upgrades  (with  user  benefits  of  more  up-to- 
date  and  effective  avionics). 

The  response  of  most  delegates  to  the  papers 
presented,  and  to  the  symposium  as  a  whole,  was 
positive,  as  indicated  by  replies  to  the  questionnaire 
circulated  to  attendees.  Three  out  of  five  replies  gave 
the  symposium  an  overall  score  of  between  80% 
(significant)  and  100%  (extremely  valuable)  -  that  is. 
the  return  exceeded  or  far  exceeded  the  individual’s 
contribution.  Virtually  all  the  remainder  considered  it  to 
be  generally  relevant  or  important,  scoring  between 
50%  and  80%.  There  was  disappointment  from  a  few 
specialists  at  the  lack  of  depth  in  papers  covering  their 
subjects,  though  this  was  to  be  expected  in  an 
Unclassified  symposium.  However,  most  of  those 
attending  thought  the  symposium  was  well  balanced, 
informative  and  valuable. 
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1.  INTRODUCTION 

It  is  indeed  an  honor  and  a  privilege  for  me  to  be  given  the 
opportunity  to  provide  this  opening  address  to  such  a 
distinguished  audience  from  NATO,  National  Governments, 
industry  and  research  institutions  at  this  NATO-wide 
symposium  on  "Advanced  Architectures  for  Aerospace 
Mission  Systems".  I  hope  that  all  of  us  will  benefit  from  the 
exchange  of  ideas  and  information  to  be  presented  here. 

This  technology-oriented  symposium  with  emphasis  on 
advances  in  advanced  architectures  for  aerospace  mission 
systems  design  and  development  will  give  us  the  opportunity 
to  review  current  and  future  trends  of  teclmology,  to  study  the 
use  of  advanced  avionics  architecture  systems  and  design,  the 
advantages  in  relation  to  current  systems  and  to  focus 
attention  on  the  cooperation  and  exchange  of  information  and 
ideas  between  the  operations  and  research  and  development 
establishments. 

My  message  today  will  focus  on  the  requirements  for 
advanced  avionics  systems,  architectures,  interoperability, 
standardization  and  the  implications  for  the  way  equipment  is 
currently  contracted  for  and  built. 

2.  MAIN  BODY 

Performance,  availability  and  costs  of  airborne  weapon 
systems  are  increasingly  being  determined  by  the  avionics 
system,  its  sensor  systems,  embedded  computing  systems  and 
associated  software. 

Fast  evolving  capabilities  of  sensors  and  real-time  computing 
systems  enable  the  fulfilment  of  new  and  far  reaching 
requirements  with  respect  to  system  effectiveness  and  system 
availability  and  to  implement  new  functionalities  such  as: 

•  sensor  fusion,  which  means  the  consolidated  presentation  of 
terrain,  threats,  obstacles  and  targets  for  an  integrated  tacti¬ 
cal  situation  display  ("Situation  Awareness") 

•  automatic  target  detection  and  target  classification, 

•  on  board  threat  analysis, 

•  reduction  of  crew  workload  tlirough  automation  of  cockpit 
functions, 

•  comprehensive  presentation  of  the  overall  situation 
(including  the  collection  and  assessment  of  current 
operating  conditions  of  the  weapon  system  through  intelli¬ 
gent  onboard  test  and  diagnosis  systems, 

•  in-flight  information  exchange  by  jam  resistant  data  links 
throughout  the  own  and  friendly  forces, 

•  cooperative  tactics. 


•  increase  in  the  mission  performance  and  mission  success 
probability  by  resource  -  sharing  and  reconfiguration  of 
mission  critical  functions, 

•  surveillance  and  reconnaissance,  in  particular  detection, 
identification  and  tracking  of  highly  mobile  targets. 

These  new  capabilities  are  of  especial  importance  since  the 
number  and  variety  of  airborne  systems  are  decreasing  while 
at  the  same  time  one  weapon  system  has  to  perform  different 
roles  and  missions. 

Reductions  in  the  defense  budgets  require  that  these 
improvements  need  to  be  made  with  minimum  development 
and  procurement  costs  while  at  the  same  time  reductions 
manpower  require  that  the  availability  of  the  weapon  systems 
needs  to  be  provided  with  less  maintenance  and  lower 
personnel  demands. 

This  requirement,  combined  with  changing  operational 
scenarios  which  demand  an  essentially  higher  degree  of 
flexibility,  mobility  and  interoperability  for  airborne  weapon 
systems  within  the  alliance,  require: 

•  a  high  degree  of  test-  and  diagnosis  capability  up  to  the 
module  level  without  external  test  means, 

•  reduced  (two  level)  maintenance  concept, 

•  improvements  in  Tum-around  Time  and  Mean  Time  To 
Repair  (MTTR), 

•  lower  and  simplified  spares  provisioning, 

•  high  degree  of  standardization  and  compatibility  with  other 
weapon  systems  within  the  alliance  through  reduction  of 
the  variety  of  avionic  modules, 

taking  into  account  the  existing  requirement  of  30  days  or 
150  hours  maintenance  free  operation  during  crisis  and  war¬ 
time  scenarios. 

Furthermore  Advanced  Architectures  must  support  for  those 
system  engineering  aspects  which  are  related  to  changing  or 
updating  the  system,  which  means  in  essence  that  open 
system  qualities  must  be  achieved.  Open  system  qualities  are 
defined  as  those  features  that  are  supported  by  the  system 
architecture,  which  reduce  the  effort  required  for  changing, 
enhancing  or  upgrading  the  systems. 

Present  NATO  airborne  systems  incorporate  avionics  consist¬ 
ing  of  many  different  types  of  electronic  assemblies  and  sub- 
assemblies  that  have  been  designed  in  accordance  with  appli¬ 
cation  and  manufacturer  specifications  There  is  little  use  of 
commonality  in  the  implementation  of  assemblies  or  in  the 
components  used  in  various  systems  apart  from  a  few  rare 
exceptions.  Consequently  aircraft  systems  are  constructed 
from  a  large  number  of  different  components  all  of  which 
require  maintenance. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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Tlus  variety  of  components  generates  high  operational  costs 
and  problems  when  upgrading  or  adapting  systems.  It  also 
means  that  the  scope  for  improvement  of  reliability  is  limited 
due  to  the  costs  of  pursuing  this  for  all  the  individual  items. 

Further,  since  commonality  is  not  exploited  in  the  develop¬ 
ment  of  components,  this  results  in  high  development, 
acquisition  and  operational  costs  as  well  as  unsatisfactory 
system  efficiency  and  availability. 

These  problems  are  aggravated  for  future  systems  where 
systems  with  greater  complexity  are  required  with  higher 
degrees  of  automation  and  special  functions  for,  in  some 
cases,  only  brief  mission  phases. 

In  addition  to  the  hardware,  the  system  software  components 
will  both  increase  in  quantity  and  become  increasingly  more 
complex.  It  is  well  known  that  the  costs  of  software  develop¬ 
ment  and  subsequent  maintenance  form  a  major  part  of  total 
system  costs.  This  is  not  helped  by  having  to  create  software 
to  different  application  standards  for  every  application  due  to 
lack  of  commonality  in  hardware. 

To  attempt  to  meet  the  objectives  of  reduced  Life  Cycle 
Costs,  improved  mission  availability  and  increased  technical 
and  operational  interoperability  there  needs  to  be  a  move 
away  from  conventional  avionic  systems.  The  direction  of  this 
move  is  towards  integrated  avionics  systems. 

Integrated  avionics  means  designing  the  elements  or  compo¬ 
nents  to  work  together  as  part  of  a  total  system,  i.e.  taking  a 
total  system  design  approach  from  the  start.  The  basis  of  the 
physical  integration  approach  is  the  exploitation  of  com¬ 
monality.  To  achieve  this,  common  modular  building  blocks 
and  their  interfaces  must  be  clearly  defined  together  with 
rules  governing  their  use  in  a  way  which  does  not  constrain 
their  use  through  lack  of  flexibility.  The  integrated  avionic 
elements  or  building  blocks  can  comprise  both  hardware  and 
software  modules. 

hitegration  can  also  be  applied  during  a  total  system  approach 
to  the  avionic  functions.  This  functional  integration  requires 
determination  of  the  way  in  which  individual  avionic  func¬ 
tions  are  managed  within  a  system  by  grouping  similar  func¬ 
tions  into  "integration  areas"  (such  as  CNI  or  EW  suites). 

The  process  by  which  integrated  avionics  are  generated 
should  be  clearly  distinguished  from  that  of  conventional 
avionics  (or  systems)  integration.  The  latter  is  used  to  mean 
the  process  of  bringing  together  elements  designed  as  sepa¬ 
rate  sub-systems  often  with  little  regard  for  a  total  system 
approach. 

In  conclusion,  the  above  objectives  will  be  met  by  a  move 
towards  a  modular  integrated  avionics  architecture. 

The  preceding  discussion  introduced  the  concept  of  integrated 
avionics  using  hardware  and  software  building  blocks.  How¬ 
ever,  the  integrated  avionics  system  will  be  constructed  from 
both  common  and  non-common  elements.  The  non-common 
elements  will  include  sensor  front  ends,  effectors  and 
actuators,  and  software  which  is  application  specific,  all  of 
which  have  to  carry  out  very  specific  functions.  This  may 
extend  to  include  other  hardware  or  software  for  which 
insufficient  contribution  to  cost  or  operational  advantages 
have  been  demonstrated  through  the  application  of  com¬ 
monality. 

The  above-mentioned  problem  areas  can  only  be  solved  by 
the  consequent  application  of  advanced  avionics  architectures 
(Integrated  Modular  Avionics,  "IMA").  Standardized  hard¬ 
ware  and  software  modules  will  be  used  which  can  be 
applied  over  a  full  variety  of  weapon  systems  and  which  can 
be  interconnected  in  such  a  way  that  a  fault  tolerant,  recon- 
figurable  system  architecture  can  be  implemented. 

While  the  external  interfaces  and  characteristics  of  the 
modules  will  be  left  to  the  implementer,  so  allowing  the 


maximum  use  to  be  made  of  the  latest  technological  develop¬ 
ments,  particularly  those  available  via  Commercial  of  the 
Shelf  Components  (COTS), 

The  different  avionic  modules  will  be  intercoimected  via 
standardised  interfaces  by  advanced  databusses  and  networks 
with  high  data  rates  and  will  jointly  provide  mission-oriented 
functions  (e.g.  navigation,  identification,  fire  control).  The 
operational  reliability  will  be  guaranteed  by  multiple  and 
redundant  use  of  similar  modules.  General  purpose  module 
such  as  data-,  signal  and  graphics  processors,  trans¬ 
mitters/receivers,  power  supplies  and  interfaces  will  be  inte¬ 
grated  in  a  core  and  combined  with  modules  for  special  func¬ 
tions  such  as  special  purpose  signal  processors.  The  use  of 
the  same  modules  will  result  in  large  quantities  during  pro¬ 
duction  and  thus  reduce  procurement  costs  tremendously.  The 
amount  of  maintenance  will  be  reduced  by  simple  exchange 
of  modules  at  the  flight  line. 

The  advantages  of  advanced  avionics  architectures  with 
respect  to  selected  operational  properties  can  be  described  as 
follows: 

•  System  Survivability: 

Consolidated  situation  presentation  and  signature  reduc¬ 
tion  tlirough  sensor  fusion;  real  time  data  exchange  with 
cooperating  forces,  integrated  presentation  of  the  informa¬ 
tion  in  the  cockpit. 

•  System  Availability: 

From  the  present  average  of  a  number  of  hours  to  up  to  30 
days  or  1 50  flying  hours  maintenance  free  operation,  intro¬ 
duction  of  a  two  level  maintenance  concept  (only  exchange 
of  faulty  components)  with  reduce  requirements  for  per¬ 
sonnel  (numbers,  training). 

•  Multimission  Capability: 

Simplified  adaptation  of  the  weapon  system  in  the  in 
service  phase  through  additional  hardware  modules  and 
operational  software. 

•  Mission  Success  Probability: 

Guaranteed  mission  capability  of  the  avionics  system  after 
failure  of  single  components  due  to  functional  redundancy 
tluough  multiple  available  modules,  graceful  degradation 
of  the  system. 

•  Mission  Effectiveness: 

Improved  target  recognition  and  identification  in  real  time 
through  sensor  fusion  and  tactical  decision-aiding  func¬ 
tions. 

•  Interoperability  and  Deployment: 

hnproved  mission  and  logistic  support  due  to  fewer  stan¬ 
dardized  module  types  which  are  cross-serviceable  and 
improved  maintenance.  Improved  interoperability  from  an 
operational  point  of  view. 

•  Life  Cycle  Cost: 

Reduced  procurement  costs,  simplified  spares  provisioning 
through  smaller  number  of  module  types.  Savings  through 
reduced  servicing  requirements. 

Only  advanced  avionics  architectures  will  provide  the  simul¬ 
taneous  availability  of  all  these  advantages  in  a  weapon 
system. 

However,  with  these  advantages  come  many  implications  for 
the  way  equipment  is  currently  contracted  for  and  built.  The 
integrated  system  design  increases  enormously  both  the 
system  complexity  and  the  potential  for  interactions  between 
sub-systems.  At  the  same  time  it  blurs  the  traditional  lines  of 
responsibility  that  exist  in  the  industry  and  it  will,  therefore. 


require  a  very  careful  and  systematic  design  approach  if 
integrated  systems  are  to  be  put  together  successfully.  To 
implement  such  highly  integrated  systems,  very  close  collabo¬ 
ration  between  systems  engineers  from  different  avionic, 
airframe  and  software  suppliers  will  be  required. 


3.  CONCLUSIONS 

In  summary,  we  in  NATO  need  to  ensure  that  our  important 
technical  achievements  in  the  field  of  "Advanced 
Architectures  for  Aerospace  Mission  Systems"  find  their  way 
into  improved  avionic  equipment  for  combat  forces  in  order 
to  enhance  our  defense  capabilities.  This  is  after  all  our 
overall  objective.  We  must  improve  the  cooperation  and 
exchange  of  information  among  the  nations  of  the  alliance. 
We  must  move  toward  cooperative  development  projects  that 
will  lead  to  affordable  equipment  for  NATO  while  at  the 
same  time  reducing  the  proliferation  of  systems  and  the 
associated  problems  of  interoperability  and  high  logistic 
support  cost.  The  dialogue  between  user  and  experts  from 
government,  academia  and  industries  must  be  continuous 
because  we  need  your  knowledge  and  assistance  to  improve 
today's  systems  to  counter  tomorrow's  threat. 

Symposia  like  this  can  be  of  great  value  in  promoting  this 
process  and  all  of  you  are  encouraged  to  address  yourselves  to 
the  problems  which  I  have  briefly  mentioned.  I  am  extremely 
pleased  to  be  the  speaker  for  the  opening  address  and  feel 
privileged  to  recognize  the  efforts  made  in  organizing  this 
symposium.  I  would  like  to  take  this  opportunity  to  personally 
and  on  behalf  of  the  German  Ministry  of  Defense,  express 
special  thanks  to  AGARD,  and  all  those  who  have  con¬ 
tributed  in  organizing  what  promises  to  be  a  very  productive 
week. 
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1.  ABSTRACT 

We  will  explore  the  question  of  where  avionics 
architectures  are  today,  considering  the  Joint  Strike 
Fighter  and  the  evolution  of  open  system  approaches 
from  the  PAVE  PACE  and  PAVE  PILLAR  programs  of 
the  1980's.  The  recent  work  extends  today's  notions  of  a 
unified  software  and  hardware  approach  to  core 
processing  and  a  common  interconnect  between 
architectural  elements,  not  only  to  sensor  or  signal 
processing,  but  toward  the  apertures  themselves  and  the 
system  development  environment.  We  shall  take  a 
broad  view  of  the  problem  that  includes  RE  electronics, 
interconnect,  operating  systems  and  application  software 
development,  processing  hardware,  and  the  system 
development  environment  itself. 

The  architectural  extensions  discussed  here  are  made  in 
the  context  of  the  basic  long  term  technology  trends  of 
more  digital  sensor  processing  and  preprocessing,  higher 
performance  analog-to-digital  converters,  lightwave 
technology  for  both  signal  distribution  and  routing,  and 
software  structures  that  reduce  development  expense, 
while  increasing  the  supportability  and  portability  of 
applications  software.  Future  RF  electronics  modules 
will  be  waveform  independent  and  support  multifunction 
apertures  in  a  given  spectrum  for  a  selected  bandwidth, 
with  a  strong  impact  on  affordability  since  the  RF 
sensors  and  their  associated  electronics  correspond  to 
some  70  percent  of  avionics  fly-away  cost. 

We  will  show  how  decoupling  the  explicit  interactions 
of  various  system  elements  simplifies  development  and 
system  integration  by  removing  unwanted  design 
dependencies  and  providing  upgrade  paths  for  cost 
effective  technology  insertion,  with  minimum  system 
breakage.  These  techniques  will  be  used  to  implement 
the  principles  of  modularity,  scale  up,  and  ability  to 
upgrade  that  have  become  part  of  the  today’s  open 
system  approaches  and  will  be  even  more  important  in 
the  future  as  the  opposite  poles  of  capability  and 
affordability  govern  both  new  systems  and  upgrades.  A 
coherent  integrated  architecture  that  promises  more 
affordable  development,  implementation,  and  support  is 
presented  as  the  answer  to  the  question,  “Where  are  we 
going?" 


2.  AVIONICS  SENSORS 

Avionics  providing  affordability  and  low  risk  is  the 
expectation  in  RF  architectures.  This  is  specifically  true 
on  current  programs  in  which  a  50  percent  reduction  in 
avionics  cost  over  the  previous  architectures  is  the  goal. 
In  the  digital  domain,  processing  architectures  can  take 
advantage  of  commercial  developments  -  that  is  not  the 
case  in  the  RF  domain. 

Today’s  inventoried  sensors  use  federated  approaches  that 
provided  single  function  operation  with  minimal 
integration  with  other  sensors.  This  approach  makes 
upgrades  difficult  and  costly  while  locking  the 
government  into  the  hardware  developer.  Adding  new 
technologies  requires  redesigns  to  the  hardware  and 
software  due  to  the  tight  coupling  of  the  architecture. 
Overcoming  these  issues  requires  the  development  of  a 
highly  integrated  concept  with  the  attributes  of 
piecewise  integration,  minimal  module  types,  near- 
aperature  digitizabon,  adaptable  to  platform  and  mission 
changes,  and  independence  of  the  software  from  hardware 
implementation.  Hence,  an  open  system  architecture 
with  a  framework  for  defining  building  block  elements 
with  well  defined  interfaces  and  top-level  functionality  is 
needed.  Our  philosophy  is  to  define  interfaces  between 
functions  that  support  three  or  four  generations  of 
growth  before  a  redesign  is  required. 

The  integration  approach  taken  by  several  programs, 
extending  from  PAVE  PILLAR  and  PAVE  PACE, 
looks  to  architectures  with  common  hardware  and 
software  interfaces  for  a  low  cost  solution.  Current 
programs  are  pursuing  this  goal  by  developing  common 
receiver  modules  that  can  be  utilized  by  multiple 
functions.  These  programs  are  moving  the  industry  in 
the  right  direction,  but  offer  only  a  small  step  toward  the 
higher  levels  of  integration  required  to  see  a  major 
payoff  in  cost,  weight,  and  performance.  Higher  levels 
of  integration  will  be  achieved  through  the  migration  of 
the  digital  interface  outward  toward  the  aperture,  thereby 
placing  the  traditional  analog  signal  processing 
completely  in  the  digital  domain. 

As  the  key  technologies,  such  as  the  Delta/Sigma  (AI) 
analog-to-digital  converters  (ADC)  increase  in 
performance,  the  network  interconnect  and  the  signal 
processing  resources  must  be  capable  of  transferring  and 
operating  on  higher  data  rates  for  broader  bandwidths. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  "Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 


1-2 


Future  network  interconnects  will  be  based  on  photonic 
technology  that  are  transparent  to  communication 
protocols.  Current  wavelength  division  multiplexing 
(WDM)  techniques  being  developed  by  commercial 
industry  provide  in  excess  of  3  Thz  of  bandwidth  per 
fiberoptic  link  which  could  simplify  the  wiring  in 
aircraft  and  move  the  processing  closer  to  the  aperature. 
Issues  that  require  futher  attention  include  the  areas  of 
maintainability  in  military  environment  and  connectors. 

3.  ARCHITECTURE 

3.1  Today’s  Architecture 

Today’s  architectures  can  be  most  easily  described  in 
terms  of  their  characteristics.  We  have  moved  from 
federated  to  at  least  partially  integrated  structures,  but 
commonality  among  functional  modules  is  still  a  goal 
rather  than  a  reality.  Many  fielded  architectures  have 
been  modified  or  adapted  to  include  1980’s  digital 
technology.  Backplanes  and  interconnect  networks  are 
separate  entities. 

The  use  of  application  specific  integrated  circuits  is 
commonplace,  although  the  total  number  of  circuits 
employed  remains  very  small,  usually  a  few  thousand 
units  at  best.  Lightwave  technology  has  been  introduced 
but  only  initially  exploited. 

The  advantages  of  building  to  standard  interfaces  is 
recognized,  but  existing  efforts  have  been  concentrated 
on  military  oriented  standards  which  have  achieved  little 
or  no  following  in  the  commercial  marketplace.  There  is 
still  considerable  debate  as  to  whether  commercial 
standards  can  satisfy  military  requirements  for  realtime, 
low  latency  operation,  fault  detection,  and  fault 
tolerance. 

Software  is  still  structured  around  realtime  executives  or 
highly  customized  kernels.  Most  application  software  is 
still  highly  coupled  to  the  execution  software  in  fielded 
systems.  Techniques  for  application  reuse  are  primitive 
or  have  yet  to  demonstrate  scale-up.  Operational  flight 
programs,  taken  together,  usually  represent  less  than  a 
million  lines  of  code.  These  flight  programs  are  written 
in  variety  of  languages  including  JOVIAL,  CMS-2,  and 
Ada. 

Affordability  has  improved  on  a  per  function  basis,  but 
the  increase  in  functional  requirements  has  resulted  in  an 
overall  increase  in  flyaway  costs.  Today’s  situation  is 
marginal  at  best. 

3.2  Impact  of  Needs,  Technology,  and  Trends 
By  considering  what  is  really  important  in  an 
architecture  we  establish  a  context  for  our  projections  of 
where  the  combination  of  needs,  technology,  and 
evolving  ideas  are  likely  to  take  us. 


Affordability  stands  at  the  top  of  the  list  of  presently 
perceived  needs.  Closely  related  are  scale  up,  technology 
insertion,  reuse  of  existing  software,  and  the  flexibility 
of  new  software.  The  cost  of  the  RF  subsystem 
presently  dominates  avionics  system  costs,  while 
software  costs  are  rising  rapidly  and  becoming  a  major 
life  cycle  cost  component.  Tomorrow’s  architecture 
must  be  implementation  independent  at  least  one  layer 
away  from  the  point  of  insertion  of  system  upgrades. 

Tomorrow’s  architecture  will  use  description  languages 
to  allow  virtual  prototyping  of  system  tradeoffs,  while 
preserving  requirements  tractability.  Effective  approaches 
to  fault  isolation  and  reconfiguration  will  also  be 
necessary.  Similarly,  development  support,  integration, 
and  maintenance  environments  are  highly  desirable. 

Everything  changes!  Remember  when  a  VHSIC- 
implemented  MIL-STD-1750B  computer  was  the  answer 
to  all  present  and  anticipated  needs?  The  parallel 
interconnect  bus  and  Futurebus-t-  were  successive 
answers  for  a  suitable  follow-on  MIL-STD-1553B. 

There  is  a  new  addition  to  the  major  processor  families  - 
-  Intel’s  x86.  Motorola’s  PowerPC,  and  Sun 
Microsystem’s  SPARC  -  at  least  every  two  years. 
Whether  we  have  entered  a  period  of  rapidly  changing 
interconnect  approaches  -  Scalable  Coherent  Interface 
(SCI),  Serial  Express,  Fibre  Channel,  and  Asynchronous 
Transfer  Mode  (ATM)  -  is  not  so  clear. 

If  we  are  to  avoid  the  significant  development  costs  of 
military-only  solutions,  we  must  solve  the  problems  of 
a  continuing  supply  of  “soon  to  be  out  of  production” 
solutions,  or  architect  systems  that  allow  the  insertion 
of  new  technology  with  minimum  disruption  to 
supported  functions.  If  the  inability  to  introduce  new 
technology  is  a  constraint  imposed  by  the  architecture, 
then  tight  coupling  between  elements  of  the  architecture 
is  certainly  one  of  the  causes. 

Tight  versus  loose  coupling  has  typically  been  a 
performance  driven  argument.  Shared  memory  versus 
message  passing  is  a  classic  example.  Loose  coupling 
may  introduce  a  degree  of  independence  among  elements, 
but  the  extra  communication  and  corresponding  delays 
and  processing  overhead  decreases  performance,  perhaps 
in  critical  areas. 

It  is  important  to  remember  that  previous  solutions 
sought  to  optimize  the  hardware  implementation,  given 
the  technology  available  at  a  point  in  time,  and  to  make 
the  solution  common  to  as  many  platforms  as  possible 
to  provide  economies  of  scale.  But  a  realistic 
consideration  of  the  scale  of  commercial  versus  military 
requirements  leads  to  the  inescapable  conclusion  that  all 
the  military  requirements  we  could  aggregate  through 
commonality  have  no  appreciable  effect  on  price  or 
delivery,  when  compared  to  commercial  demands  for  the 
same  part  numbers. 
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Tight  coupling  was  the  most  efficient  solution,  but  with 
all  the  elements  of  a  system  highly  interdependent, 
upgrades  were  costly  and  difficult.  Major  portions  of  the 
previous  implementation  were  abandoned  during 
upgrades. 

Has  today’s  technology  reached  the  point  where  we  are 
processing  capability  rich  and  can  now  concentrate  on 
formulating  more  desirable  architectures  based  on 
considerations  of  scale  up,  adaptability,  ability  to 
upgrade,  and  life  cycle  affordability?  We  appear  to  be 
data  processing  rich  -  in  terms  of  raw  capability. 

Perhaps  we  will  be  signal  processing  rich  after  the  turn 
of  the  century. 

The  more  complex  an  architecture  the  more  expensive, 
the  more  difficult  to  upgrade,  and  the  greater  the 
disruption  with  the  insertion  of  new  technology.  Global 
shared  memory  approaches  and  complex  cross-bar-like 
switches  may  be  fine  for  small  systems,  but  as  soon  as 
we  attempt  to  scale  them  the  complexity  increases 
exponentially  to  the  number  of  system  elements. 
Conscious  efforts  at  keeping  a  simple,  unified  approach 
are  needed. 

Integrated  architectures  have  been  introduced  to  promote 
resource  sharing  and  flexibility  for  the  future.  They 
complement  digital  processing  trends  and  the  increasing 
implementation  of  functionality  in  software.  Proponents 
of  older  federated  approaches  argue  that  integrated 
architectures  are  more  difficult  to  integrate  because 
essential  modularity  and  separation  of  functions  is  lost 
to  supposed  resource  optimization.  There  is  a  question 
of  the  applicability  of  digital  -  in  portions  of  the  RF 
subsystem  -  and  the  software  architecture  approach. 
Integrated  architectures,  properly  defined,  will  continue 
to  be  a  major  source  of  avionics  cost  reduction. 

We  define  an  architecture  in  terms  of  interfaces  to 
establish  modularity,  foster  competitive  approaches  to 
functional  implementation,  and  to  simplify  integration. 
Minimizing  and  simplifying  the  number  of  interfaces 
simplifies  integration.  A  principle  advantage  of  a  unified 
interconnect  network  is  that  it  minimizes  the  number  of 
interconnects  or  network  interfaces.  Well-defined 
interfaces  are  the  means  by  which  newer,  more  economic 
technology  insertion  is  achieved.  Well-defined  interfaces 
also  promote  competition  by  allowing  different 
suppliers,  both  present  and  future,  to  compete  effectively 
for  upgrade  and  support  opportunities. 

The  avionics  system  interconnect  is  a  prime  example  of 
the  need  for  effective  standards  and  also  presently  one  of 
the  most  frustrating  areas  of  architecture  definition. 
While  a  unified,  or  single  interconnect  protocol 
simplifies  integration,  it  makes  the  selection  of  the 
protocol  that  much  more  important. 

We  have  experienced  a  long  period  of  interconnect 
“stability”  in  which  MIL-STD-1553B  dominated 
military  systems  while  ethernet  and  VME  were  the 


principle  network  and  backplane  standards,  respectively. 
In  the  commercial  world,  we  have  entered  a  period  of 
flux  in  which  new  standards  such  as  the  parallel  interface 
(PI)  bus,  FutureBus-t,  Fibre  Channel,  and  the  Scalable 
Coherent  Interface  (SCI),  Asynchronous  Transfer  Mode 
(ATM),  and  Serial  Express  are  appearing  or  disappearing 
at  roughly  the  product  cycle  time  of  a  microprocessor 
family  member  (we  see  no  connection,  incidentally). 

The  question  is  whether  that  is  a  temporary  instability, 
while  the  next  major  standard  emerges,  or  a  prolonged 
period  of  rapidly  changing  standards.  The  answer  may  be 
crucial  to  the  success  of  open  architectures. 

We  assume  that  the  military  approach  will  follow  the 
commercial  approach  with  due  consideration  of  realtime 
and  latency  needs  as  well  as  environment.  It  is  hazardous 
to  speculate  on  the  right  solution  until  we  get  an 
adjudication  of  Serial  Express  in  the  commercial 
marketplace.  Presently,  commercial  designs  seem  to  be 
moving  to  VME64  backplanes  and  100  Base  T  ethernet 
for  local  area  networking.  At  this  point  we  doubt  that 
ATM  will  catch  on  at  the  desktop.  Serial  Express  is 
being  considered  for  small  work  group  interconnect 
applications. 

Previous  systems  have  been  requirements  driven.  This 
has  led  to  worst  case  designs  for  worst  case  scenarios  - 
possibly  with  penalties  for  ordinary  operation.  We  are 
entering  a  period  where  we  will  be  requirements 
compliant,  rather  than  requirements  driven.  By  virtue  of 
improved  scalability  and  the  recognition  that  future 
technology,  if  affordable,  will  upgrade  performance  at 
regular  intervals.  Commercial  components,  bought  to 
manufacturer’s  part  numbers,  in  standard  or  optional 
volume  production  packaging  will  dictate  the 
performance  of  these  upgrades.  Affordability  has  become 
the  predominant  driver  in  the  procurement  of  new 
military  avionics. 

As  programmable  hardware  solutions  become  less  and 
less  expensive  as  a  function  of  improvements  in 
microelectronics  technology,  applications  software 
increases  in  relative  importance  and  cost  in  the  system 
solution.  Yesterday’s  custom  hardware  is  becoming 
today’s  firmware  and  field  programmable  gate  arrays,  and 
will  become  tomorrow’s  software.  This  means  that 
efficient  methods  of  writing  independent  applications  to 
a  common  application  interface  that  facilitate  integration 
will  become  even  more  important  in  developing, 
supporting,  and  upgrading  avionics  systems. 

The  principal  method  of  decoupling  applications 
software  from  the  execution  of  hardware  is  through  a 
layered  operating  system.  The  application  programming 
interface  to  the  operating  system  is  critical  to  the 
efficient  development  of  application  code,  particularly 
during  system  integration.  Thus,  we  find  that  the 
software  architecture  is  perhaps  the  most  important 
element  of  the  system  architecture. 
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4.  SOFTWARE 

The  complexity  of  avionics  software  systems  have 
changed  dramatically.  Over  the  past  few  decades, 
avionics  software  has  grown  from  a  few  thousand  bytes 
running  on  a  dedicated  processor  to  be  close  to  a  million 
lines  of  source  code.  Functionality  has  grown  from 
simple  navigation  and  simple  sensor  processing  to  very 
complex  cooperative  attack,  imaging,  and  information 
management  techniques. 

Beyond  the  increased  complexity,  software  must  meet 
the  procurement  challenges  of  the  future  just  like  the 
core  processing  hardware  and  interconnection  networks. 
Standards,  software  reuse,  information  architecture  offer 
some  interesting  possibilities  to  address  some  of  the  life 
cycle  cost  questions. 

We  will  try  to  understand  where  software  is  going  by 
trying  to  first  understand  the  attributes  of  today’s 
software,  and  what  is  necessary  to  meet  the  perceived 
needs  for  tomorrow. 

4.1  Today’s  Software 

Probably  the  largest  advance  in  the  past  few  years  in  the 
area  of  software  is  the  introduction  and  wide  spread 
application  of  sound  software  management.  Given  the 
growth  in  the  size  and  complexity  of  systems,  today’s 
software  organizations  focus  on  sound  software 
management.  Collection  of  metrics,  training,  process 
refinement,  reproducibility,  and  to  a  lesser  extent 
supported  by  software  tools. 

Software  management  is  clearly  an  important,  but  some 
organizations  singularly  focus  on  software  processes  - 
achieving  that  capability  maturity  model  level  five. 
Sound  software  management  processes  are  not  the  whole 
story,  but  a  combination  of  product  and  process 
innovation  is  necessary. 

There  has  been  minimal  software  technology  innovation 
in  the  past  few  decades  as  compared  to  process 
innovation.  Clearly,  some  software  technologies  like 
fuzzy  logic,  distributed  systems  techniques,  genetic 
algorithms,  and  rate  monotonic  analysis  have  made  their 
way  into  some  systems.  However,  this  does  not 
compare  to  the  innovation  seen  in  process,  processors, 
or  even  avionics  algorithms  (e.g.,  multi-target  tracking). 

Software  languages  have  changed  from  assembly  to 
JOVIAL  to  Ada,  but  software  development  techniques 
have  remained  mostly  unchanged,  and  consists  of  basic 
embedded  software  development  environments  with 
customized  debuggers  and  debugging  interfaces.  Much  of 
the  debugging  is  dependent  on  having  the  real  target 
systems  available  to  each  integrator/developer.  However, 
initial  integration  and  target  emulation  are  helping  to 
minimize  target  integration  and  test  requirements. 

Design  methods  have  not  changed  for  fielded  system; 
structured  design  has  been  practiced  for  the  past  few 


decades  with  software  reuse  being  an  after  thought. 
Object  oriented  design  is  slowly  creeping  into  systems, 
and  invesunent  in  reusable  and  maintainable  software 
appears  to  be  accepted. 

Constructive  simulation,  man-in-the-loop  flight 
simulators,  ground  based  flight  trainers,  and  operational 
flight  programs  currently  all  implement  the  same 
functions  using  common  requirements  with  different 
software  organizations  and  software  baselines.  This  can 
lead  to  a  divergence  in  system  behavior  and  “throw 
away”  simulation  software. 

Today’s  avionics  software  is  tightly  coupled  with  the 
underlying  hardware.  Device  driver  implementation  in 
application  code  is  a  common  occurrence,  and  many 
codes  are  dependent  on  the  underlying  byte  ordering  of 
the  processor.  Custom  extensions  for  the  compiler  are 
also  common.  For  example,  compiler  extensions  for 
mapping  timers  or  other  special  hardware  dependent 
functions  to  application  functions  are  expected  by  most 
avionics  organizations.  The  setting  of  explicit  processor 
priorities  and  making  explicit  calls  to  fault  and  memory 
management  code  is  also  common.  All  these  things 
make  today’s  avionics  software  less  reusable  and 
therefore  less  valuable  for  future  systems. 

Today’s  avionics  software  utilize  custom  executives  and 
operating  systems  to  preserve  processor  resources.  This 
condition  is  rapidly  changing  with  the  exponential 
increases  in  microprocessor  speeds,  and  the  advances  in 
operating  system  technology.  Today,  standards  bodies 
like  the  Institute  of  Electronic  and  Electrical  Engineering 
(IEEE)  and  the  Society  of  Automotive  Engineering’s 
Avionics  Systems  Division  (SAE-ASD)  are 
standardizing  the  application  programming  interfaces 
(API)  to  realtime  operating  systems. 

Signal  processing  software  currently  is  achieved  using 
high  order  language  for  back-end  operations  (e.g., 
tracking,  fusion,  sensor  mode,  etc.)  and  assembly 
language  for  front-end  functions  (e.g.,  waveform  timing 
control,  basic  digital  filtering,  etc.).  Technology 
programs,  such  as  Rapid  Application  Specific  Signal 
Processing  (RASSP),  have  explored  the  concept  of 
visual  programming  of  the  digital  filtering  pipelines.  In 
this  paradigm,  common  digital  filtering  operations  are 
represented  as  blocks,  and  the  visual  tool  glues  the 
blocks  together.  When  the  program  is  compiled,  the 
glue  code  is  automatically  generated,  and  the  blocks  are 
simply  library  calls  to  predefined  operations 
implemented  by  the  tool  or  chip  vendor  in  assembly 
code.  This  provides  for  quick  application  coding,  and 
efficient  runtime  performance. 

4.2  What’s  Important  in  Software 
Avionics  applications  of  the  future  must  exhibit  some 
important  characteristics  to  meet  the  needs  and 
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expectations  of  open  systems.  The  following  discussion 
lists  some  of  these  avionics  application  characteristics. 

Avionics  application  programs  should  be  portable. 
Avionics  applications  should  not  be  dependent  on 
architecture  (processor,  memory,  inter-process 
communication,  device  driver  codes,  tasking  priority, 
security,  and  fault  tolerance  attributes).  Specifically, 
avionics  applicadons  should  not  directly  incorporate 
pieces  of  device  drivers,  explicit  priority  operations, 
explicit  security  requests,  and  explicit  fault  tolerances 
requests  from  within  its  code. 

Portability  also  means  that  applicadon  software  will  be 
insulated  from  changes  in  the  processor.  Applications 
must  be  funcdonally  independent  of  the  processor  (e.g., 
produce  the  same  results  exclusive  of  dming  dependent 
features),  and  applicadons  must  be  performance 
independent  of  the  processor  (e.g.,  produce  the  same 
results  inclusive  of  temporal  events).  In  other  words, 
applicadons  should  have  the  ability  to  be  moved  from 
system  to  system  (without  change)  and  have  the 
applicadon  behave  identically. 

The  application  software  must  be  predictably  engineered 
and  specified  to  meet  both  the  funcdonal  and 
performance  specificadons  so  that  applicadon  software 
does  not  require  change  when  hardware  changes. 

Avionics  applicadons  should  be  modular.  Applications 
should  be  built  for  expansion,  and  should  not 
incorporate  policy  decisions  into  the  code.  Policy 
decisions  should  be  encoded  in  table  form  (e.g., 
waveform  priority  data  should  be  an  input  to  the  multi- 
funcdon  radio  system).  This  approach  would  allow  new 
transmission  priorities  to  be  implemented  without 
changing  the  underlying  radio  system.  Changes  would 
only  be  necessary  if  new  waveform  types  were 
introduced. 

Avionics  applications  should  be  evolvable.  Applicadon 
development  should  allow  a  continuous  transition  from 
initial  concepdon  to  flight  deployment  and  maintenance. 
Applicadons  should  not  be  treated  as  “throw  away” 
between  each  phase  of  an  aircraft  program. 

Avionics  applications  should  easily  incorporate  new 
algorithmic  codes  from  emerging  technology  programs 
(e.g.,  fusion  architecture  algorithms).  This  implies  that 
the  environments  expected  in  these  technology  program 
should  be  supported  in  the  avionics. 

Avionics  applicadons  should  be  constructed  as  muldple 
cooperative  tasks  with  priorities,  and  exchange  data  with 
priorities.  Creating  an  avionics  system  from  many 
smaller  tasks  with  discrete  priorides  supports  the 
previous  goal  of  modularity,  and  allows  the  software  to 
minimize  the  effects  of  priority  inversions. 

A  given  avionics  applications  should  not  be  able  to 
interfere  with  another  applicadon.  For  instance,  one 
application  should  not  be  able  to  write  into  another 


application’s  private  memory  space.  Applications  must 
have  a  measure  of  system  integrity  and  security  implicit 
in  their  environment.  This  is  typically  not  enforced  in  a 
standard  Ada  environment  where  the  avionics  consists  of 
a  single  program  and  program  memory  space. 

Avionics  applicadons  should  not  be  able  to  act  upon 
incomplete,  incoherent,  or  in-flux  data.  This  is  an 
application  design  goal  for  real-dme  systems,  and 
applies  to  both  shared  memory  and  message  passing 
systems. 

Avionics  applications  should  be  capable  of  being 
implemented  in  muldple  languages.  There  are  several 
cases  in  an  avionics  system  where  use  of  other 
languages  may  be  necessary  (e.g.,  signal  or  image 
processing).  Thus,  applications  should  have  the  ability 
to  make  heterogeneous  language  calls  (C-i-i-,  Assembly, 
domain  specific  language).  Clearly,  assembly  coding  is 
not  desired  because  of  its  lack  of  portability,  but  may  be 
necessary  in  some  limited  cases  to  meet  latency 
requirements. 

5.  AN  INTEGRATED  SYSTEM  APPROACH 
To  achieve  the  goals  outlined  for  avionics  software 
characteristics,  an  integrated  system’s  approach  is 
necessary.  Core  processors,  software,  and  sensors  cannot 
individually  achieve  the  benefits  of  open  systems,  but 
together  they  can  change  the  way  avionics  is  done. 

5.1  Integrated  System  Development 

Evolutionary  system  development  approaches  are  needed 
to  carry  avionics  work  products  from  requirements 
concept  through  support  without  loosing  information. 
Requirements  methods/tools  have  direct  relationships  to 
system  architecture  methods/tools,  which  in  turn  links 
direcdy  to  software  architecture  and  software  design 
elements.  The  maintenance  of  these  relationships 
through  manual  or  automated  means  is  important.  The 
challenge  here  is  not  establishing  these  relationships  for 
the  first  time,  but  maintaining  them  over  decades  of 
system  maintenance  in  a  useful  form  that  allows 
fundamental  requirements  to  change  and  have  minimal 
impact  across  the  system. 

For  example,  a  landing  beacon  system  specified  using 
today’s  methods  map  requirements  to  many  system 
architectural  components  (e.g.,  communications, 
displays,  etc.)  that  eventually  trace  to  software 
architecture  objects  and  so  on.  Thus,  the  impact  of 
removing  such  a  system  requirement  causes  a  system 
wide  ripple  effect  in  an  integrated  architecture,  but  has 
minimal  impact  in  older  “steam  gauge”  era  architectures. 
This  ripple  effect  is  primarily  caused  by  the  outdated 
process  and  methods  that  have  direct  dependencies  to  the 
older  “build  it  once”  architectural  methods. 
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If  the  processes  and  methods  were  integrated  and  focused 
on  incremental  development,  the  ripple  effect  would  be 
minimized.  Methods  that  promote  object  creation 
throughout  the  life  cycle  help  to  minimize  this  effect  by 
creating  distinct  parts  that  can  be  assembled.  These  parts 
must  be  manageable  from  end  to  end  in  the  development 
life  cycle,  but  this  only  solves  half  of  the  problem.  The 
other  half  of  this  problem  is  the  glue  between  the 
objects.  Intra-object  contracts  and  relationships  need  to 
be  established  and  maintained:  interfaces,  priorities,  fault 
management,  etc.  Defining  the  volatility  of  interface 
points  must  be  tempered  by  the  technology  half-life  of 
the  components  on  each  side  of  the  interface.  Some 
interfaces  choices  are  very  important  at  a  given  time 
because  of  technology’s  rate  of  change  (e.g.,  custom 
operating  system  interface  versus  standard  operating 
system  interface). 

This  vertical  application  approach  parallels  the  federated 
approach  to  systems.  Instead  of  the  federated  pieces 
being  the  traditional  avionics  subsystems  (e.g., 
navigation,  mission  management,  etc.),  the  pieces  are 
objects  that  result  from  system  architecture  analysis  (a 
form  of  domain  analysis).  This  process  can  be  carried 
out  iteratively,  with  change  impact  decreasing  as 
successive  layers  of  the  system  are  defined.  This  results 
in  fine  grained  objects  that  can  be  reused.  Further,  a 
fully  integrated  avionics  object  can  be  created  and 
delivered  independently. 

In  terms  of  process,  this  vertical  object  breakdown 
structure  supports  incremental  refinement  of  the  system 
by  providing  clear  interfaces.  This  allows  for 
independent  hosted  development  of  each  of  the  objects 
for  functional  capability,  and  to  some  extent  a  capability 
for  hosted  integration.  Key  to  both  hosted  development 
and  hosted  integration/test  is  a  prototyping  and 
integration  environment.  Final  platform  integration, 
meeting  timing  and  specific  device  requirements,  must 
be  done  on  the  target  processor. 

5.2  Prototyping  and  Integration 

Another  dimension  to  a  system  approach  to  avionics  is 
the  system  prototyping  and  integration  environment. 
This  environment  provides  the  surrounding  test  fixtures 
to  accomplish  both  unit  and  integration  test  in  both  a 
hosted  environment  and  final  bench  testing  on  the  target. 
The  prototyping  interfaces  also  include  the  necessary 
models  to  mimic  components  of  the  system  for  basic 
unit  test. 

This  prototyping  and  integration  support  environment 
includes  man-in-the-loop  test  fixtures  (cockpit  controls 
and  display),  sensor  domain  simulators  (infrared,  visual, 
radio  frequency,  etc.),  threat  simulators,  vehicle 
simulators,  core  processing  simulators  (if  necessary), 
and  interconnect  simulation  (if  necessary).  This  support 


environment  enables  initial  integration  testing  of  the 
system  objects  as  soon  as  possible. 

The  prototyping  interfaces  are  modeled  after  the  initial 
system  decomposition,  and  are  extensions  to  the 
interface  descriptions.  With  reasonable  fidelity  models 
for  each  system  object,  basic  unit  testing  is  possible 
using  a  newly  developed  system  object,  a  set  of  object 
models,  and  the  support  environment.  Functionality  can 
be  evaluated  on  a  host  computer  with  all  parts  of  the 
system  represented,  and  subjective  attributes  can  be 
evaluated  through  man-in-the-loop  interaction.  Priorities 
and  security  constraints  specified  during  the  system 
architecture  are  used  by  each  model  to  set  actual  tasking 
priority  and  access  limitations  during  prototyping  and 
integration. 

This  type  of  prototyping  and  integration  environment 
allows  the  avionics  functionality  to  be  evaluated  in  a 
high  productivity  environment  (on  desktop  assets).  This 
evaluation  during  this  phase  is  done  for  proper  behavior, 
not  for  efficient  resource  utilization.  This  prototyping 
and  integration  environment  does  not  address  resource 
allocation  issues,  but  must  provide  the  specific  timeline 
information  required  for  resource  estimation.  Analysis 
tools  are  used  to  estimate  processor,  memory,  and 
network  usage. 

5.3  Resource  Analysis 
Resource  analysis  balances  the  timeline  requirements 
produced  by  the  integration  environment  against  the 
various  architecture  configurations  to  arrive  at  estimated 
resource  utilization. 

The  architectural  objects  produced  by  the  system 
analysis  are  mapped  to  elements  in  an  architecture  under 
evaluation.  Thus,  specific  functionality  is  mapped  to 
specific  hardware  for  the  purposes  of  loading  and  traffic 
analysis.  The  timeline  information  from  the  prototyping 
environment  forms  the  basis  for  the  loading  profile  used 
to  stimulate  each  portion  of  the  system.  Peak  loading 
can  be  determined,  and  the  architecture  configuration 
modified  to  optimize  the  number  of  processors  or 
networks. 

Each  processing  domain  has  its  own  unique  analysis 
tools,  so  signal  processing,  data  processing,  and  network 
analysis  do  not  share  analysis  tools.  Reducing  and 
correlating  the  output  data  from  these  tools  requires 
some  simple  data  management  utilities. 

6.  CONCLUSIONS 

Integrated  architectures  will  become  the  rule  rather  than 
the  exception  for  new  systems  or  major  upgrades. 
Integration  will  proceed  rapidly  in  core  processing,  much 
more  slowly  in  the  RF  electronics. 

The  awareness  of  problems  in  technology  insertion  and 
upgrades  of  tightly  coupled  system  will  become  better 
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understood.  Simularly,  layering  of  systems  will  become 
better  understood.  Layering  of  system  software  and 
eventually  RF  hardware  will  be  used  to  reduce  the 
system  impact  of  technology  insertion.  Reduced 
performance  due  to  the  decoupling  techniques  will  be 
mitigated  by  the  more  capable  hardware  available 
through  newer  technology  implementations.  There  will 
be  an  emphasis  on  scalability  for  solving  increased 
capability  needs  and  providing  requirements-compliant 
solutions.  Modularity,  the  need  for  which  is  already 
well-established,  will  be  based  on  commercial  standards 
whose  interfaces  are  in  wide-spread  use  with 
implementations  in  volume  production.  We  will  order 
components  to  a  manufacturer’s  part  number  based  on 
compliance  with  an  industry  benchmark  or  standard. 

In  the  interest  of  reducing  complexity  and  simplifying 
integration  there  will  be  an  emphasis  on  building 
systems  out  of  sets  of  simple  structures  that  are  easily 
programmed  to  meet  a  mission  need. 

We  will  have  to  let  the  commercial  marketplace  sort  out 
interconnect  solutions  for  next  generation  equipment 
before  tying  ourselves  to  a  particular  standard.  This  may 
take  two  or  three  years  and  considerable  patience.  We 
must  also  consider  the  possibilities  of  dealing  with 
realtime  and  high  priority  data  at  the  upper  layers  of  the 
protocol  stack,  rather  than  insisting  on  physical  level 
solutions  that  the  commercial  marketplace  has  little 
interest  in.  Custom  approaches  for  the  military  will 
have  a  strong  appeal  from  a  requirements  viewpoint,  but 
they  will  be  increasingly  unaffordable. 

Perhaps  the  greatest  changes  will  come  in  software. 
Software  architecture  will  become  the  dominating  factor 
in  avionics  architecture.  The  operating  system,  the 
system  development  environment,  and  provisions  for 
software  rehosting  and  reuse  will  be  among  the  most 
important  considerations.  The  layering  that  makes 
application  software  independent  of  the  execution 
hardware  will  be  accomplished  in  the  operating  system. 
The  application  programming  interface  is  critical  to 
application  independence,  portability,  and  software  reuse. 

Change  is  also  coming  rapidly  to  the  RF  area.  There 
will  be  modularity  based  on  generic  interfaces  that  will 
have  implementation  independence,  yet  align  with 
overall  technology  ffends.  A  handicap  here  is  the  lack  of 
standards  and  the  limited  success  of  previous  efforts  have 
proved  too  dependent  on  the  digital  implementation 
technology.  Digital  implementations  will  have  a  strong 
effect  on  these  interfaces  as  programmable  digital 
approaches  emerge  for  functions  in  the  200  Mhz  to  2 
Ghz  spectrum. 

We  have  stressed  the  need  for  architecture  independence 
of  hardware  and  software  and  hence  the  need  for 
technology  independence  in  future  architectures.  But 
architectures  must  also  consider  major  technology 
trends.  Is  this  an  oxymoron?  We  don’t  think  so. 


Independence  of  hardware  and  software  deals  with  the 
independence  of  hardware  and  software  implementations. 
Major  technology  trends  refer  to  the  fundamental  way  in 
which  we  approach  solutions:  analog  versus  digital, 
hardware  versus  software,  or  the  interconnect  bandwidth. 
The  architectural  notions  presented  here  are  based  on 
assumptions  about  the  future  paths  of  technology  trends. 

We  think  there  is  a  strong  trend  toward  digitization  of 
previously  analog  functions.  This  will  have  a  major 
effect  on  approaches  to  RF  functions,  most  immediately 
on  communications,  navigation,  and  identification. 
Custom  hardware  will  be  replaced  by  programmable 
hardware  with  strongly  increasing  capability  per  dollar 
benefits.  Much  of  the  functionality  of  future  avionics 
systems  will  be  defined  in  software  and  the  code  size  of 
operational  flight  programs  will  increase  dramatically. 
Finally,  we  think  that  light  wave  signal  distribution 
will  replace  coaxial  cable  signal  distribution  with 
corresponding  benefits  in  reduced  weight  and  increased 
bandwidth.  The  latter  will  allow  distributed  integrated 
system  to  evolve. 
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•  Background 

It  has  been  proven  throughout  history  that 
information  can  provide  the  warfighter  with 
an  edge  needed  to  win  the  battle  and 
ultimately  the  war.  For  this  reason  we  have 
seen,  over  time,  increasing  investments  in 
data  collection  and  dissemination  systems. 
Today,  these  systems  include  national, 
theater,  and  tactical-level  capabilities  that 
provide  a  variety  of  data  types.  Current 
examples  of  theater  collection  systems 
include  AWACS,  E-2C,  JSTARS,  Rivet 
Joint,  Guardrail,  EP-3E,  ES-3A,  and 
Predator,  Global  Hawk,  and  Darkstar  UAVs. 
Tactical  collection  systems  include  wingman, 
other  flight  groups,  Forward  Air  Controllers 
(FACs),  and  Hunter,  Pioneer,  and  Gnat 
UAVs.  These  systems  provide  electronic 
intelligence  (FLINT),  imagery  intelligence 
(IMINT),  and  radar  intelligence  (RADINT). 
Only  recently  has  this  data  been  made 
available  to  the  warfighter  in  near-real-time 
(NRT).  This  data,  when  appropriately 
processed  and  converted  to  information,  can 
be  used  by  the  warfighter  for  situation 
awareness  and  targeting  to  enhance 
survivability  and  lethality. 

Taken  together,  and  properly  orchestrated, 
these  off-board  collectors  form  the  support 
structure  for  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR).  The  addition  of  a 
Command  and  Control  (C^)  function  is 
required  to  complete  the  off-board  portion  of 
a  SoS  construct.  Effective  C^  is  based  upon 
authority  combined  with  the  ISR  information 
needed  for  decisions  on  appropriate  target 
weapon  pairing.  These  decisions  must 
support  both  the  normal  Air  Tasking  Order 
(ATO)  cycle  generation  and  NRT  C^  for 
time-critical-targeting  (TCT). 

The  USAF  Scientific  Advisory  Board’s 
(SAB)  New  World  Vistas  study  introduces 
the  concept  of  “Global  Awareness”  as  critical 


for  the  21st  century.  “Global  Awareness”  is 
defined  as  the  “affordable  means  to  derive 
appropriate  information  about  one  or  more 
places  of  interest  after  a  delay  which  is  short 
enough  to  satisfy  operational  needs.”  Various 
other  ISR  agencies  have  also  placed  an 
emphasis  on  support  military  operations 
(SMO).  For  example,  the  Defense  Advanced 
Research  Projects  Agency  (DARPA)  has 
placed  “comprehensive  battlefield 
awareness”  as  first  among  its  top  ten  military 
priorities.  The  objective  of  these  efforts  is  to 
improve  the  effectiveness  of  the  warfighter, 
while  leveraging  the  ISR  assets  toward  cost 
reductions  of  new  lethal  tactical  systems. 

•  Problem 

It  is  precisely  the  escalating  cost  of  tactical 
systems  that  has  placed  affordability  as  a  top 
priority  in  the  development  of  the  JSF 
weapon  system.  The  JSF  Program  Office 
(JSF/PO)  has  adopted  four  “pillars”  that 
focus  the  efforts  of  the  potential  weapon 
system  contractors  (WSC’s).  These  pillars 
are: 

-  Affordability 

-  Lethality 

-  Survivability 

-  Supportability 

Ongoing  studies  by  the  WSCs  surround  and 
support  a  balanced  look  at  these  pillars  with 
the  figure  of  merit  being  life-cycle  cost 
(LCC). 

A  premise  adopted  by  the  JSF  program  is 
that  by  judicious  choices  in  the  sources  for 
tactical  information,  reductions  in  on-board 
avionics  can  be  achieved.  The  questions 
confronting  the  WSCs  is  how  to  gain  these 
cost  cuts  without  reducing  the  Warfighter’s 
capability  or  transferring  the  cost  from  the 
warfighter  community  to  the  ISR 
community.  These  questions  must  first  be 
confronted  by  a  proper  understanding  of  the 
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trade-space.  Figure  1  shows  that  the  trade- 
space  has  four  elements:  (1)  the  assets  that 
can  be  brought  to  bear  by  the  ISR 
community,  (2)  the  structure  of  the 


architecture,  (3)  the  components  of  the  on¬ 
board  avionics  suite  and  (4)  the  concept  of 
operations  (CONOPs)  under  which  the  war 
fighting  objectives  will  be  addressed. 


Figure  1  -Components  of  the  SoS  Trade  Space 


It  is  true  that  the  JSF  program  does  not  have 
total  control  of  aU  the  elements  involved  in 
the  trades,  but,  as  stated  earlier,  the  support 
communities  are  posturing  their  planning  to 
provide  SMO.  For  this  reason,  JSF  program 
interaction  with  the  various  agencies  involved 
have  proven  to  be  very  cooperative.  More 
flexibility  exists  in  performing  the  trades  than 
might  first  be  assumed.  The  interchange  to 
date  has  provide  a  clear  definition  of  what 
legacy  assets  are  available  but  a  somewhat 
less  clear  view  of  future  assets.  Indigenous  to 
the  US  department  of  defense  (DoD)  is  the 
process  called  the  Five  Year  Development 
Plan  (FYDP).  DoD  uses  the  FYDP  to  show 


Congress  goals  and  plans  for  weapon  and 
support  systems  development.  The  problem 
is  that  funding  usually  will  not  provide  for  aU 
the  developments  that  DoD  requests. 
Therefore,  the  C'’ISR  support  systems 
available  to  the  JSF  in  circa  2010  can  only  be 
postulated. 

This  ambiguity,  while  complicating  the 
process,  does  not  preclude  some  trades. 
Certainly,  some  existing  systems  will 
continue  to  be  in  operation  by  that  time,  while 
other  new  high  priority  systems  will  almost 
certainly  receive  funding. 
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•  Potential 

To  understand  the  potential  support  that  can 
be  expected  from  the  ISR  community,  an 
examination  of  legacy  and  high-priority 
assets  have  led  to  broad  categorizations  of 
ELINT  and  SIGINT.  From  an  aircraft 
perspective  the  use  of  off-board  data  also 
falls  into  two  broad  categories:  (1)  situation 
awareness  (SA),  which  can  be  related  to  the 
pillar  of  survivability  and  (2)  targeting,  which 
can  be  related  to  the  pillar  of  lethality.  Figure 


2  shows  the  most  probable  relationships 
between  these  functions.  ELINT  data  has 
limitations  for  targeting  because  of  issues  on 
accuracy.  As  a  result,  ELINT  may  only  be 
used  for  targeting  in  the  case  of  weapons 
with  the  appropriate  seeker.  Similarly, 
IMINT  is  rarely  used  for  SA  because  of 
latency.  Efforts  are  underway  within  the  ISR 
establishment  to  reduce  latency  that  will  have 
some  impact  on  this  situation.  Figure  2  also 
shows  where  command  and  control  (C^)  fits 
in  the  overall  concept  of  operations. 
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Figure  2  -  Off-board  Data  Supports  Lethality  &  Survivability 


Another  observation  on  the  use  of  off-board 
data  is  depicted  in  Figure  3,  where  a  forward 
line  of  troops  (PLOT) -centric  and  an  aircraft- 
centric  view  of  the  current  ISR  are  shown. 
The  FLOT-centric  view  shows  that  the 
availability  of  ISR  support  diminishes  with 
aircraft  penetration  beyond  the  FLOT.  This 
situation  presents  a  need  to  the  JSF  for 


autonomous  operation  during  deep 
penetration  into  enemy  territory.  Similarly, 
the  aircraft-centric  case  shows  that  utility  of 
ISR  support  decreases  as  range  decreases 
with  respect  to  the  JSF  based  upon  latency  or 
timeliness  of  the  ISR  support.  Hence,  two 
issues  that  must  be  addressed  with  ISR 
support  is  availability  and  latency  or 
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timeliness.  The  good  news  is  that  these  community, 
issues  are  being  addressed  by  the  ISR 
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Figure  3  -  Problem:  Asset  Availability  vs.  Range 


It  is  clear  that  the  cost  of  on-board  avionics  is 
directly  correlated  with  the  level  of  off-board 
support  from  the  ISR  assets  in  the  SoS 
context.  Figure  4  indicates  that  a  balanced 
approach  must  be  formulated  to  affordably 
meet  the  needs  of  the  JSF  warfighter.  The 
figure  highlights  several  of  the  issues  relevant 
to  achieving  the  desired  balance.  On  the 
avionics  functions  side,  the  power- aperture- 
product  (PAP)  of  the  radar,  the  sensitivity  of 
the  electronics  support  measures  (ESM),  the 
number  and  types  of  communications  links 
and  the  amount  of  on-board  processing  must 
be  traded  against  the  off-board  support  in  the 
areas  of  availability  and  latency  of  target  and 
threat  updates,  which  may  require  the  re¬ 
tasking  of  ISR  assets,  and  overall  battle  space 
awareness.  The  figure  also  introduces  the 


concept  of  cooperative  operations  between 
aircraft  for  synergistic  effect.  These 
operations  might  include  cooperative  ranging, 
cooperative  jamming  or  sensor  sharing. 

Figure  5  shows  what  a  vision  of  the  JSF 
battlefield  might  look  like  in  circa  2010  with 
the  emphasis  on  existing  ISR  assets  to  keep 
the  figure  unclassified.  However,  it  is  clear 
from  examination  of  the  figure  that  there  are 
many  potential  ISR  sources  with  a  variety  of 
data  types.  Currently,  these  assets  have  a 
variety  of  datalinks  and  protocols  that  present 
connectivity  problems.  However,  the  Joint 
Chiefs  of  Staff  (JCS)  within  the  DoD  have 
chosen  Link- 16  as  the  primary  tactical  data 
dissemination  datalink  of  the  future  for 
purposes  of  standardization  both  within  the 
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US  military  and  coalition  forces.  Current 
plans  also  call  for  distributed  common 
ground  stations  (DCGS)  for  processing  of  all 
types  of  data  from  the  various  collection 
assets.  The  DCGS  supports  both  the  Joint 
Intelligence  Center  (JIC)  and  the  C^  nodes 


within  the  theater.  The  most  likely  scenario  is 
that  SA  data  will  be  broadcast  via  the  Global 
Broadcast  Service  (GBS)  and  that  NRT 
targeting  data  will  arrive  at  the  JSF  via  the  C^ 
nodes  along  with  tasking/re-tasking 
command  authority. 
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Figure  4  -  Avionics  Cost/Capability  Varies  With  Off-board  Support  Level 


From  an  engineering  perspective  this  SoS 
architecture  is  the  natural  extension  to  the 
integration  process  that  WSCs  have 
historically  been  performing  during  the 
development  of  new  weapon  systems.  Figure 
6  depicts  how  the  various  levels  of 
cormectivity  can  be  done  in  a  new  SoS 
paradigm.  The  JSF  on-board  avionics 
architecture  must  be  capable  of  this 
expansion  to  include  off-board  “busses.”  The 
most  likely  condition  is  that  these  off-board 
busses  will  perform  three  functions:  (1) 


make  broadcast  intelligence  available  to  JSF, 
(2)  support  the  command  and  control 
linkages  and  (3)  support  cooperative 
operation  between  platforms,  either  like-  or 
diverse  types. 

Today,  there  are  many  datalink  networks 
which  support  a  partial  implementation  of  the 
desired  connectivity,  e.g.,  TADIL-A, 
TADIL-B,  TADIL-C,  etc.  The  shortfall  is 
that  these  existing  links  provide  networks  for 
platforms,  but  not  many  fighter-attack- 
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bomber  aircraft.  The  DoD  is  making  a 
concerted  effort  to  minimize  the  number  of 
dissimilar  datalinks  and  standardize  on  Link- 
16/TADE.-J  data  networks  for  the 
dissemination  of  this  information  through  a 
long-term  migration  plan.  The  plan  calls  for 


the  retrofit  of  Link- 16  on  almost  all  legacy 
platforms,  including  fighter-attack-bomber 
aircraft,  with  a  life  span  of  more  than  a  few 
years.  This  choice  also  provides 
interoperability  with  several  coahtion  forces. 
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Figure  5  -Emerging  JSF  Battlefield  Vision 


This  dissemination  architecture  challenge  can 
be  met  by  either  of  two  concepts:  off-board 
processing  with  subsequent  dissemination  or 
dissemination  followed  by  a  primary 
challenge  for  the  WSCs  in  developing  the 
JSF  is  to  leverage  the  off-board  portion  of 
on-board  processing.  While  off-board 
processing  and  dissemination  might  be 
preferable,  legacy  off-board  systems  have 
driven  the  JSF  requirement  toward  on-board 


data  processing.  The  reality  is  that  both  on¬ 
board  and  off-board  processing  will  occur 
with  dissimilar  functions  for  that  processing. 
The  net  result  is  the  evolution  of  a  SoS 
paradigm  which  drives  the  need  for  an 
advanced  information  management  system 
(AIMS)  on  the  JSF.  AIMS  then  becomes  an 
enhanced  man/machine  interface  which  is 
needed  to  enable  the  pilot  to  deal  effectively 
with  off-board  and  on-board  data.  AIMS 
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will  transform  this  data  into  information  and 
determine  information  relevance  to  current 
mission  task.  Advanced  information 
management  concepts  such  as  information 
poUcy  hypothesis  development,  evaluation, 
and  execution  are  currendy  being  developed 
for  the  JSF.  This  technology  will  increase 
the  Signal-to-Noise-Ratio  (SNR)  of  the 


man/machine  interface.  In  the  context  of 
information,  signal  is  the  system  declaration 
of  tactically  relevant  information.  By 
contrast,  noise  is  the  system  declaration  of 
irrelevant  information.  AIMS  combined 
with  SoS  will  provide  the  JSF  pilot  with  the 
desired  information  advantage  over  the 
adversary. 
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Figure  6  -  SoS  From  an  Engineering  Point-of-View 


Figure  7  shows  a  potential  JSF  functional 
avionics  architecture  that  could  embody  the 
AIMS  concept.  AIMS  is  shown  pictorially 
by  the  Core  Data  Fusion  and  Core  Mission 
Management  elements.  Fire  Control, 
Navigation  and  Fault  Management  are  not 
new  concepts  but  do  have  new  functionality 
within  the  AIMS  concept,  e.g.  failure  of  an 
on-board  sensor  can  place  a  higher 
dependence  upon  off-board  support  and 
might  allow  the  mission  to  proceed  with  off- 


board  or  wingman  targeting  and/or  re-tasking 
to  a  different  objective 

A  preliminary  study  conducted  by  Lockheed- 
Martin  and  called  the  On-board/Off-board 
Information  Fusion  and  Management  Study 
determined  that  the  total  data  that  might  be 
available  to  the  JSF  would  likely  be 
overwhelming  to  the  pilot  and  developed  the 
concept  of  information  management  policies. 
These  policies  control  the  information  shown 
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to  the  pilot  at  any  given  instant  of  time  and 
are  a  sophisticated  extension  to  the  common 
“declutter”  display  feature  of  many  of 
today’s  tactical  aircraft.  Policies  are  defmed 
during  pre-mission  planning  and  transferred 
to  the  aircraft  by  the  data  transfer  unit  (DTU). 
These  information  policies  are  sensitive  to 
mission  phase  and  tactical  situation,  e.g., 
there  are  class  policies  (fighter,  bomber, 
SAM,  etc.),  geometric  policies  (range  and 
angle),  interaction  policies  (fighter  on 


intercept  course  to  ownship,  etc.),  mixed 
policies  (combinations  of  other  policies),  etc. 
study  included  an  implementation  of  the 
concept  in  a  mission  simulation  and  was 
reviewed  by  pilots  from  the  US  Air  Force, 
Navy  and  Marines.  Ongoing  studies  and 
planned  demonstrations  are  scheduled  to 
explore  the  efficacy  of  the  constituent 
components  of  this  SoS/AIMS  concept  as 
will  be  shown  later  in  Figure  8. 
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Figure  7  -  Potential  JSF  Architecture  Supporting  SoS  &  NRT  Targeting 


•  Process 

The  foregoing  paragraphs  have  discussed  the 
problem  and  the  potential  solutions  posed  by 
the  SoS  paradigm  without  defining  a  process 
to  achieve  desired  goals.  During  the  on-going 
Concept  Definition  Phase,  the  JSF/PO,  via  a 
Force  Process  Team  (FPT)  and  Operational 


Advisory  Group  (OAG),  has  defined  a  top- 
level  process  to  determine  the  JSF/SoS 
requirements.  The  product  of  this  process  is 
annual  Joint  Interim  Requirements 
Documents  (JIRDs)  that  focus  on  different 
aspects  of  JSF  requirements.  Current  plans 
call  for  the  SoS  attributes  to  be  defined  in 
1997  via  JIRD  El  with  SoS  requirements  to 
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be  defined  in  1998  with  JIRD  IV  and  final 
validation  of  SoS  requirements  to  occur  in 


1999  resulting  in  the  final  Joint  Operational 
Requirements  Document  (JORD). 


Figure  8  -  SoS  Trade  Study  Plans 


Underneath  this  top-level  process,  several 
study  plans  are  being  developed  that  look  at 
various  needs  as  shown  in  Figure  8.  The 
CONOPs  study  defines  and  matures  the 
CONOPs  element  of  the  trade  space  shown 
in  Figure  1.  The  C'^ISR  study  will  build  upon 
existing  study  results  and  be  updated 
interactively  as  the  ISR  community  plans  for 
asset  development  solidify.  Additionally,  the 
results  of  JSF  trades  will  influence  O'lSR 
planning  to  provide  developments  better 
suited  to  JSF  needs.  The  model  study 


addresses  short-falls  in  current  operational 
analysis  models  relative  to  incorporation  of 
off-board  and/or  fusion  influences.  These 
models  are  then  used  to  determine  the  cost- 
effectiveness  of  various  CONOPs  in  the  SoS 
paradigm.  Finally,  the  JSF  Weapon  System 
Information  Architecture  (WSIA)  study 
provides  the  “bottom  line”  on  LCC  for  the 
various  CONOPs.  It  is  obvious  that  each  of 
these  studies  interact  with  each  other  as 
indicated  by  the  underlying  arrows  in  Figure 
8. 
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Figure  9  -  SoS  Requirements  Process 


Figure  9  shows  the  flow-down  of 
requirements  process  that  precipitates  the 
trade  studies  indicated  in  Figure  8  and  gives  a 
context  for  studies  in  the  overall  JSF 
Strategy-to-Task-to-Technology  (S-T-T) 
process.  Both  Figure  8  and  Figure  9  indicate 
that  the  studies  are  supported  hy 
demonstrations  to  reduce  the  risk  to  the  JSF 
program  at  Engineering  and  Manufacturing 
Development  (E&MD).  Some  of  the  risk 
reduction  demonstrations  may  be 
accomplished  by  high-fidelity  simulations 
(referred  to  as  the  Virtual  Strike  Warfare 
Environment,  VS  WE,  and/or  Virtual 
Avionics  Prototypes,  VAPs,  depending  upon 
context)  of  the  SoS  concepts,  while  others 
may  be  attained  by  “brass-board”  hardware 
coupled  with  the  simulations  or  actual 
laboratory  or  flight  tests.  It  is  clear  from 
Figure  9  that  metrics  will  have  a  valuable  part 
in  the  trade  study  process.  The  JSF  Force 


Process  Team  (FPT)  will  determine  these 
metrics  as  part  of  the  S-T-T  process.  The 
proof  of  the  SoS  concept  will  be  shown  in 
real-world  military  exercises,  e.g.  Red  Flag, 
Green  Flag,  or  Joint  Warfare  Interoperability 
Demonstrations  (JWID).  All  these  efforts  are 
directed  toward  the  goal  of  the  JSF  program 
which  is  to  achieve  a  “low-risk”  system 
design  prior  to  entry  into  E&MD.  The 
process  outlined  in  Figure  9  is  ongoing,  will 
continue  throughout  the  upcoming  JSF 
Concept  Demonstration  Phase  (CDP)  and 
will  ultimately  define  the  SoS  attributes  and 
requirements  for  the  JSF  JORD  at  the 
beginning  of  the  21st  century. 

•  Conclusion 

Complete  autonomous  mission  capability  for 
tactical  aircraft  is  no  longer  affordable  nor 
necessary  in  view  of  the  SoS  concept.  The 
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JSF  will  rely  upon  national,  theater,  and 
tactical-level  ISR  to  provide  long-range  target 
detection,  location,  and  identification.  On¬ 
board  systems  will  employ  cues  from  the 
off-board  collectors  but  will  still  be  required 
to  provide  targeting  and  weapon  employment 
capability  as  a  result  of  latency  and  accuracy 
issues  with  ISR  collectors.  However,  the 
resulting  JSF  on-board  sensors  will  be  much 
less  complex  in  terms  of  power-aperture 
product,  aperture  complexity  and/or  system 
sensitivity:  the  current  cost  drivers  in 
avionics.  Total  weapon  system  performance 
will  be  maintained  through  correlation  and 
fusion  of  off-board  information  with  on¬ 
board  sensor  data.  In  effect,  off-board  data, 
correlation,  and  fusion  technology  will  enable 
a  smaller  and  less  complex  on-board  sensor 
system  to  perform  like  that  of  a  much  higher 
performance/cost  system.  Use  of  wingman 
data  will  allow  on-board  systems  to  be 
designed  for  less  severe  simultaneous  mode 
capabilities.  Lower  cost,  non-interferometer, 
apertures  on  multiple  aircraft  will  be 
managed  to  provide  highly  accurate  range 
and  bearing  data.  The  implementation  of  a 
SoS  concept  will  enable  an  affordable  JSF 
which  can  be  procured  in  large  enough 
numbers  to  replace  end-of-life  aircraft  for  the 
US  and  NATO  allies. 
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1.0  SUMMARY 

The  complexity  of  today’s  military  system  has  caused  the 
priority  of  affordability  to  rise  to  an  unprecedented  level 
among  system  requirements.  An  increasing  number  of 
government  and  defense  industry  leaders  are  relying  on 
commercial  off-the-shelf  {COJ^)  products  with  the  associated 
economies  of  scale  and  use  of  non-developmental  items  (NDI) 
to  meet  this  requirement. 

The  affordability  benefits  of  COTS  and  NDI  for  military 
systems  are  subject  to  several  other  factors.  For  example,  as 
the  need  for  products  capable  of  operating  in  a  hostile 
military  environment  increases,  the  number  of  products  and 
vendors  meeting  these  requirements  decreases.  In  addition, 
military  systems,  which  traditionally  have  been  expected  to 
survive  for  long  periods  of  time,  are  subjected  to  two 
commercial  phenomena  that  occur  simultaneously  -  product 
prices  decrease  over  time  while  technology  provides  an 
increase  in  product  performance.  The  latter  factor  results  in  a 
dichotomy  summarized  as  parts  obsolescence. 

This  paper  identifies  additional  military  system  issues  and 
current  commercial  trends  and  postulates  how  these  trends 
can  be  used  to  meet  affordability  requirements.  The  latter 
includes  illustrated  use  of  open  system  standards  combined 
with  pre-planned  product  improvement  (P^I). 

2.0  AFFORDABILITY  -  AN  INTERNATIONAL 
PROBLEM 

The  leaders  of  North  Atlantic  Treaty  Organization  (NATO) 
countries  are  responsible  not  only  for  the  security  of  their 
countries  and  for  strengthening  the  defense  posture  of  NATO 
as  a  whole  but  also  for  the  financial  welfare  of  their  people. 
The  latter  responsibility  has  led  to  a  decline  in  military 
budgets  and  has  resulted  in  defense  system  affordability 
problems  for  all  NATO  countries.  To  meet  this 
responsibility,  NATO  Advisory  Group  for  Aerospace 
Research  &  Development  (AGARD)  members  and  NATO 
defense  leaders  are  actively  pursuing  a  total  mission  system 
architecture  approach  that  includes  continuous  system 
upgrade  through  technical  improvements  and  the  potential 
use  of  cost-competitive  commercial  off-the-shelf  (COTS) 
equipment. 

2.1  Premise 

The  theme  for  the  sixth  symposium  sponsored  by  the 
AGARD  Mission  System  Panel  (MSP)  describes  past 
avionics  systems  as  “stand-alone,  dedicated  suites 
[developed]  to  perform  a  single  function  such  as  [electronic 
warfare],  fire  control,  communications,  etc.”  Utilization  of 


unique  resources  and  functions  for  each  of  the  dedicated 
suites  contributes  to  higher  initial  nonrecurring  as  well  as  life 
cycle  costs.  Examples  include  the  initial  cost  of  fault 
tolerance  (e.g.,  component  redundancy)  and  life  cycle  costs 
for  sparing,  documentation,  training,  etc.  The  symposium’s 
theme  encourages  research  and  development  that  will  enable 
use  of  robust  architectures  -  architectures  that  utilize  common 
digital  modules,  common  software,  shared  radio  frequency 
(RF)  and  electro-optical  (EO)  apertures,  and  standard 
hardware  and  software  interfaces,  i.e.,  commodities  that 
stimulate  commercial  investment  for  profits  other  than  from 
military  sales.  An  increasing  number  of  government  and 
defense  industry  leaders  are  relying  on  commercial 
investment  to  create  commodities  capable  of  meeting  defense 
system  requirements.  These  commodities  have  the  potential 
to  become  non-developmental  items  (NDIs)  for  the  military 
and  hence  reduce  nonrecurring  system  costs.  Today’s  NDIs 
generally  fit  into  one  of  the  following  three  categories: 

•  Commercial  off-the-shelf  (COTS) 

•  Rugged  off-the-shelf  (ROTS) 

•  Military  off-the-shelf  (MOTS). 

2.2  Economy  of  Scale 

The  design  and  development  cost  of  NDIs  in  general  and 
COTS  in  particular  is  amortized  across  the  quantity  of 
marketable  components.  The  amortization  results  in  the 
economy  of  scale,  i.e.,  as  the  quantity  of  sales  for  a  specific 
item  increases,  the  cost  of  each  item  decreases. 

Unfortunately,  commercial  demands  usually  drive  the  design 
of  COTS  products.  Subsequently,  as  illustrated  in  Figure  1, 
changes  required  to  meet  hostile  environments  result  in  fewer 
vendors,  the  need  for  fewer  items,  and  a  subsequent  increase 
in  cost. 

For  military  systems  to  gain  from  the  economy  of  scale,  the 
defense  industry  must  contribute  to  the  design  of  new 
products,  i.e.,  merge  military  requirements  into  COTS 
products  (eliminate  the  need  for  differences  between  COTS, 
ROTS,  and  MOTS). 

3.0  FUNDAMENTAL  ISSUES 
Aerospace  mission  systems  are  complex  collections  of 
platform  subsystems  and  functionality.  Historically,  each 
dedicated  aerospace  mission  system  suite  consists  of  unique 
equipment  and  associated  algorithms.  The  complexity  of 
integrating  unique  equipment  adds  to  system  development 
time  as  well  as  to  initial  system  design,  procurement,  and  life 
cycle  costs. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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Environment 

Figure  1 .  Military  System  NDIs  and  the  Economy  of  Scale 


Affordability  dictates  that  new  defense  system  programs  seek 
a  balance  between  the  initial  nonrecurring/procurement  costs 
and  life  cycle  costs  as  illustrated  in  Figure  2.  For  peacetime 
military  systems,  this  cost  is  distributed  over  a  relatively  long 


period  of  time,  i.e.,  a  new  strike  fighter  can  easily  take  10  (or 
more)  years  from  conception  to  first  article  delivery  and 
remain  in  service  in  excess  of  20  years. 


Non¬ 
recurring  and 
initial  costs 


Reliability,  spares, 
training  (Integrated 
Logistics  Support) 


Aerospace  system  life  exceeds  commercial  products 


Figure  2.  Product  Life  Cycle  is  Typically  Longer  for  Defense  Systems 


Because  of  the  quantities  involved  in  the  development  of 
commercial  products,  nonrecurring  costs  can  be  amortized 
over  a  shorter  period  of  time.  The  end  product  is 
subsequently  subjected  to  the  two  simultaneously  occurring 
commercial  electronic  industry  phenomena  illustrated  in 
Figure  3.  The  result  is  a  decrease  in  product  prices  while 
technology  provides  an  increase  in  product  performance. 
Both  contribute  to  a  shorter  product  life  cycle,  which,  from  a 
traditional  military  perspective,  creates  a  dichotomy  referred 
to  as  parts  obsolescence. 

Commercial  industry  has  taken  advantage  of  this  phenomena 
by  creating  a  commodity  market.  A  commodity  market 
enables  the  incremental  development  and  integration  of 
systems  using  open  system  components.  Examples  of 
commercial  open  system  components  include  the  personal 
computer  (PC),  PC  clones,  local  area  network  (LAN) 
protocol/adapters  (e.g.,  Ethernet  adapters),  system  interface 
buses/adapters  (e.g..  Small  Computer  System  Interface 
(SCSI)  and  Peripheral  Component  Interconnect  (PCI) 
adapters),  communication  protocol/stacks  (e.g.,  Transmission 
Control  Protocol/Internet  Protocol  (TCP/IP)  adapters)  and 
shrink-wrapped  software.  The  open  system  concept 
encourages  profit-motivated  competition  which  results  in  a 
variety  of  COTS  products,  the  use  of  new  technology,  an 


increase  in  the  number  of  suppliers,  and  ultimately,  a  decrease 
in  product  costs. 

3.1  A  New  Role  for  System  Developers 

For  the  development  of  new  military  avionics  systems  the 
challenge  is  how  to  gain  the  performance  and  affordability 
advantages  of  COTS  without  creating  a  parts  obsolescence 
problem  that  is  significantly  more  severe  than  before.  When 
system  developers  move  toward  a  greater  demand  for  COTS 
and  a  smaller  demand  for  components  from  military 
suppliers,  the  few  remaining  military  suppliers  will  disappear 
and  system  developers  will  become  responsible  for  the 
problem  of  parts  availability.  This  is  a  significant 
responsibility  since  the  functionality,  quality,  and  reliability 
previously  guaranteed  by  military  suppliers  will  be  gone. 
Unfortunately,  this  will  not  be  a  responsibility  that  will  be 
assumed  by  COTS  suppliers.  This  void  in  the  quality  chain 
must  be  filled  in  order  to  guarantee  the  delivery  of  systems 
that  are  supportable,  maintainable,  and  reliable. 

This  new  role  for  system  developers  will  require  a  much 
closer  relationship  with  COTS  suppliers.  Without  this 
relationship,  a  system  developer  will  not  be  successful  in 
placing  militaiy  requirements  on  commercial  suppliers  or 
reacting  to  product  changes  that  result  from  changes  in 
commercial  markets. 
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Figure  3.  A  Product  of  COTS  Economics  -  Parts  Obsolescence 


In  order  to  benefit  from  the  advantages  of  commercial 
markets,  the  system  developer  must  understand  these 
commercial  markets  and  therefore  the  motivation  behind  the 
suppliers  into  these  markets.  Only  then  will  military  system 
developers  be  able  to  anticipate  ehanges  that  will  be  made 
due  to  trends  in  processing  architectures,  memory  designs, 
interconnect  protocols,  bandwidths,  supply  voltages,  etc. 
Additionally,  the  system  developer  must  take  responsibility 
for  understanding  the  capability  and  therefore  the  limitations 
of  commercial  components  in  military  environments.  By 
accepting  these  responsibilities,  the  system  developer  can 
plan  for  the  insertion  of  new  COTS  technology  as  the 
commercial  markets  evolve  rather  than  suffer  the  cost  and 
schedule  impacts  of  unanticipated  and  inevitable  changes  in 
COTS  components. 

3.2  COTS  Mandates  Continual  Technology  Insertion 

Military  systems  have  life  cycles  that  are  significantly  longer 
than  the  typical  12-  to  18-month  life  cycle  for  COTS 
products.  Most  commercial  PC  suppliers  release  new 
configurations  every  3  to  4  months  and  these  configurations 
are  usually  supported  for  12  to  18  months.  For  military 
systems,  a  system  usually  needs  to  be  supportable  for  20 
years  or  more.  Unfortunately,  supporting  a  20-plus-year 
system  with  elements  that  will  be  obsolete  in  12  to  18  months 
creates  obsolescence  problems  even  before  the  engineering 
model  development  (EMD)  is  complete.  This  is  the  type  of 
problem  now  being  faced  by  the  prime  contractors  of  U.S. 
aircraft  currently  under  development.  Discontinued 
commercial  production  of  critical  components  will  force 
programs  into  either  a  significant  redesign  or  a  costly  lifetime 
buy. 

Due  to  the  mismatch  in  product  life  cycles,  the  use  of  COTS 
mandates  the  continual  insertion  of  commercial  technology. 
The  challenge  is  to  develop  requirements,  certification,  and 
qualification  processes  that  enable  the  continual  replacement 
of  elements  during  the  entire  life  of  the  system  without  the 
expense  of  total  system  recertification  and  requalification. 

The  entire  system  must  be  developed  using  a  building  block 
approach.  The  architecture  must  lend  itself  to  the  efficient, 
continual  replacement  of  the  building  blocks  as  COTS 
products  evolve.  The  enabling  step  in  achieving  the  benefits 
of  COTS  is  not  in  the  selection  of  the  right  processor 
instruction  set  architecture  (ISA)  or  interconnect  protocol  but 
instead  is  in  the  development  of  an  architecture  that  cost- 
effectively  supports  the  inevitable  replacement  of  its  elements 
during  its  service  life.  The  ability  to  continually  upgrade 
elements  results  in  a  system  that  continues  to  grow  gracefully 
in  capability  and  eliminates  the  need  for  very  expensive  and 
lengthy  system  upgrades. 


For  new  platform  aerospace  mission  systems  to  benefit  from 
the  inherent  cost  savings  associated  with  COTS  products, 
both  the  military  establishment  and  the  defense  industry  must 
focus  early  on  integrated  logistic  support  (ILS); 

•  Combine  legacy  and  new  product  technology 

•  Schedule  system  additions/upgrades 

•  Schedule  transition  to  new  products 

-  Parts  obsolescence  avoidance 

-  Parts  substitution 
Cost  optimal  sparing. 

Concentrating  on  the  above  objectives  will  also  reduce  the 
cost  of  future  upgrades  to  existing  platforms.  However, 
neither  this  paper  nor  a  symposium  totally  dedicated  to  the 
subject  can  be  expected  to  answer  all  the  questions  associated 
with  the  above  objectives.  We  can  only  offer  some 
observations  and  illustrate  hypothetical  solutions  we  believe 
will  improve  system  affordability. 

4.0  OBSERVATIONS/HYPOTHETICAL  SOLUTIONS 

1.  The  financial  welfare  of  our  individual  countries  and 
people  require  us  to  develop  lower  cost  aerospace 
mission  systems.  The  U.S.  Department  of  Defense 
(DoD)  is  moving  aggressively  to  streamline  the 
acquisition  system.  Passage  of  the  Acquisition 
Streamlining  Act  in  1994  (FASTA  94)  under  than 
Deputy  Secretary  of  Defense,  Dr.  William  J.  Perry, 
addressed  use  of  commercial  specifications  and 
standards.  The  U.S.  DoD  is  actively  seeking  to 
implement  improvements  in  the  acquisition  process'. 

2.  The  defense  industry  must  understand  and,  where 
savings  are  real,  mimic  commercial  industries  use  of  the 
open  system  commodity  market. 

3.  COTS  suppliers  need  to  be  monitored  continually  to 
assess  changes  in  their  business  models  that  will  impact 
military  system  procurement. 

4.  Open  systems  start  with  the  use  of  both  hardware  and 
software  interface  standards.  Creative  building  blocks 
that  use  interface  standards  and  provide  company  profits 
keep  the  supplier  engine  running. 

5.  The  defense  industry  and  a  typical  commercial  consumer 
place  different  environmental  demands  on  products. 

This  is  perhaps  the  most  complex  task  facing  the  defense 
industry  -  how  to  eliminate  the  need  for  expensive 
ROTS  and  MOTS  components. 

6.  To  achieve  the  potential  benefits  of  COTS  products,  a 
new  requirements,  certification,  and  qualification 
methodology  must  be  employed  by  the  defense  industry. 
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The  methodology  must  support  the  inevitable  insertion 
of  new  technology  during  the  life  cycle  of  the  system. 

7.  The  model  for  the  COTS  market  is  based  on  a  much 
shorter  product  life  cycle  than  the  historical  model  for 
defense  system  platforms.  Use  of  the  COTS  model  will 
inevitably  lead  to  the  use  of  pre-planned  product 
improvement  (P^I)  by  the  defense  industry. 

The  scope  of  this  paper  prevents  us  from  providing  an  in- 
depth  definition  for  P^I.  However,  we  will  attempt  to 
illustrate  ongoing  activities  compatible  with  the  above 
observations,  hypothetical  solutions,  and  the  concept  of  P’l. 

5.0  ILLUSTRATIONS 

The  Lockheed  Martin  Tactical  Defense  System  (TDS) 
division,  located  in  Eagan,  Minnesota,  USA,  has  used  the 
previous  observations  and  hypothetical  solutions  to  form  a 
COTS-based  P^I  strategy  for  next  generation  aerospace 
mission  systems.  Recognition  of  the  need  for  a  strategy 
began  with  participation  on  the  U.S.  Navy’s  Next  Generation 
Computer  Resources  (NGCR)  High  Speed  Data  Transfer 
Network  (HSDTN)  working  group.  The  objective  of  the 
NGCR  HSDTN  working  group  was  to  adopt  a  standard 
backplane  interconnect  network  for  military  systems  that 
would  eliminate  the  bandwidth  and  scalability  limitations  of 
“party  line”  backplane  buses. 

In  July,  1993,  the  HSDTN  working  group  adopted  the  IEEE 
1596-1992  Scalable  Coherent  Interface  (SCI)  as  a  standard 
backplane  network.  The  SCI  standard  was  originally  created 
by  international  personnel  from  commercial  industry  and 
academia^.  The  standard  was  completed  in  1992.  The  intent 
of  the  working  group  was  to  meet  the  growing  need  of  next 
generation  hardware  and  software  for  scalable  interconnect 


bandwidth.  The  SCI  protocol  has  since  been  adopted  by  the 
Society  of  Automotive  Engineers  (SAE)  Aerospace 
International  AS-2  Unified  Network  Interconnect  Task 
(UNIT)  working  group  for  applications  beyond  the  processor 
backplane  including  transactions  between  sensor  and  video 
subsystems,  SCI  utilizes  point-to-point  packet  protocol 
compatible  with  traditional  LAN  message  passing  while 
providing  low  latency  features  required  for  cache-coherent, 
shared  memory  access.  Bandwidth  scalability  is  achieved  by 
varying  the  interconnect  topology,  e.g.,  by  using  compatible 
ring,  n-dimensional  mesh,  and/or  switch  interconnect 
schemes. 

The  increasing  use  and  availability  of  commercial 
multiprocessing  is  being  accompanied  by  a  significant  change 
in  software  architecture.  Figure  4  illustrates  what  we  perceive 
to  be  a  major  trend  in  future  high  performance  multiprocessor 
systems.  Current  systems  allocate  application  and  operating 
system  software  to  each  node  (unit  processor  or  symmetrical 
multiprocessors).  Two  or  more  nodes  form  a  distributed 
processing  cluster  (Figure  4,  left).  However,  the  performance 
of  a  distributed  processing  cluster  decreases  as  operating 
system  overhead  for  message  exchange,  interrupt  processing, 
load  balancing,  fault  recovery,  etc.,  occurs. 

The  central  processing  unit  or  units  (CPUs)  within  each  node 
require  on-chip  cache  and  cache  mechanisms  to  achieve  their 
performance  potential.  “Support  for  synchronization  and 
memory  coherence  are  two  important  elements  of  [current 
CPU]  chip  design”’.  The  increased  use  of  symmetrical 
multiprocessors  combined  with  the  availability  of  on-chip 
cache  mechanisms  provides  the  incentive  for  the  software 
architecture  change  illustrated  in  the  remainder  of  Figure  4. 
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Figure  4.  Commercial  Trends  Include  Memory  Sharing 
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Evidence  is  growing  that  the  change  will  allow  multiple 
CPUs  to  first,  share  a  single  copy  of  the  application  software 
(Figure  4,  center)  and  ultimately,  share  a  single  copy  of  both 
the  application  and  operating  system  software  (Figure  4, 
right).  This  architecture  reduces  the  need  for  memory,  a 
significant  advantage  for  aerospace  mission  systems. 

Information  (instructions  or  data)  can  be  transferred  directly 
from  shared  memory  to  the  CPU  cache.  This  eliminates  the 
need  to  move  information  from  one  node’s  memory  to  the 
memory  of  another  node  and  reduces  operating  system 
overhead.  Movement  of  information  directly  from  the 
memory  in  which  it  is  located  to  the  CPU  cache  reduces  the 


number  of  memory  references  required.  This  change  in 
software  architecture  is  expected  to  increase  system 
performance  while  reducing  system  cost. 

Evidence  of  the  software  architecture  change  is  illustrated  by 
Intel’s  Commercial  Multiprocessor  System  shown  in  Figure 
5,  the  specification  for  which  can  be  downloaded  from  the 
World  Wide  Web.  The  specification  identifies  the  potential 
use  of  a  single  copy  of  the  operating  system  for  up  to  256 
processors”*. 

Caching  for  multiprocessing  has  traditionally  been  limited  by 
the  scalability  of  backplane  buses.  This  and  similar  needs  for 
bandwidth  is  what  led  to  the  creation  of  SCI,  IEEE  1596. 


•  Tightly-coupled,  shared  memory  architecture 

•  All  processors  able  to  execute  a  single  copy  of  the  operating  system 


Figure  5.  Commercial  Multiprocessor  Trend  Illustration 


The  need  for  high  performance  aerospace  mission  systems 
resulted  in  the  formulation  of  a  task  force  comprised  of  U.S. 
Air  Force,  Navy,  and  Marine  personnel.  The  task  force 
selected  SCI  as  a  leading  interconnect  candidate  for  the  next 
generation  Joint  Strike  Fighter  (JSF).  The  interconnect  is 
illustrated  in  Figure  6  as  the  Unified  Digital  Avionics 
Network^ 

The  SCI-based  architecture  permits  processing  modules  to 
share  memory  or  communicate  by  means  of  messages 
regardless  of  on  which  chassis  they  reside.  This  simplifies 
system  upgrade  and  supports  P^I.  For  example,  high 
performance  processing  modules  for  resource  control  and 
signal  pre-processing  can  be  located  in  the  RF  enclosure  (as 


illustrated  in  Figure  6  for  RF  sensing)  or  in  the  Integrated 
Core  Processor  enclosure  (as  illustrated  in  Figure  6  for  EO 
sensing).  The  evolving  availability  of  commercial  interface 
components  enables  the  use  of  either  a  fiber  optic  or  copper 
wire  media  and  supports  the  flexible  placement  of  modules. 
For  example,  it  is  now  possible  to  install  fiber  optic  cables  for 
initial  high  performance  RF  or  intermediate  frequency  (IF) 
communication  between  analog  modules.  Using  P^I,  the 
analog  modules  can  ultimately  be  replaced  with  digital 
modules  as  lower  cost,  higher  performance  analog-to-digital 
(A/D)  converters  become  available.  The  fiber  optic  cables 
can  now  be  used  with  SCI  protocol  for  digital  information 
transmission  and  control. 
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Figure  6.  Advanced  JSF  Architecture  Showing  Interface  Standardization 


The  availability  of  SCI  command  protocol  for  shared 
memory,  message  passing,  or  a  combination  of  both  enables 
the  interface  of  legacy  subsystems  (e.g.,  the  Vehicle 
Management  System)  with  systems  that  are  compatible  with 
the  trends  outlined  above.  SCI  simplifies  system  upgrade  and 
provides  the  infrastrueture  for  P^I. 

Cost/risk  reduetion  for  next  generation  aerospaee  mission 
systems  will  involve: 

1 .  A  mix  of  legacy  systems  and  evolving  COTS  technology 

2.  Upgrades  compatible  with  evolving  threats 

3.  Component  replacement  based  on  the  shorter  life  cycles 
of  COTS  products. 

All  require  P^I  to  benefit  from  commercial  trends  and  the 
associated  COTS  products.  Selection  of  the  interconnect  is, 
however,  a  key  ingredient.  The  interface  must  be  stable  and 
sufficient,  i.e.,  it  must  satisfy  evolving  information  exehange 
paradigms  and  bandwidth  requirements  beyond  the  life  cycle 
of  individual  products.  For  example,  the  interconneet  of 
commereial  systems  historieally  started  with  the  use  of  linear 
LANs.  As  system  use  increased,  the  requirement  for 
additional  bandwidth  was  satisfied  using  switches  compatible 
with  LAN  protocol.  We  expect  this  commercial  trend  to  be 
repeated  for  the  SCI  standard.  For  aerospace  mission 
systems,  switches  will  enable  performance  demanding 


upgrades  for  passive  target  identification,  auto  target 
recognition,  etc. 

The  authors  contend  that  for  effective  use  of  COTS  in  the 
military,  defense  contractors  must  become  involved  in  the 
development  of  commercial  products.  At  a  minimum,  this 
requires  partieipation  in  open  system  standardization 
activities  as  described  earlier.  Flowever,  other  alternatives  are 
available.  As  a  defense  contractor,  Lockheed  Martin  TDS 
opted  to  design  an  SCI  switch  capable  of  transparently 
replacing  existing  topologies.  Available  SCI  topologies  are 
shown  in  Figure  7.  The  ring  and  mesh  topologies  are 
currently  available  from  commercial  sources.  The  switch 
fabric,  however,  was  designed  by  Lockheed  Martin  TDS  to 
meet  military  system  scalability,  fault  tolerance,  and  low 
latency  requirements.  Using  low  power  CMOS  technology, 
the  switch  will  support  an  aggregate  interconnect  bandwidth 
of  P(500  Mbytes/second)  where  P  is  the  number  of  switch 
ports  available.  The  switch  is  compatible  with  both  military 
requirements  and  commercial  SCI  products  and  software 
trends.  Combined  with  evolving  commercial  products,  the 
switch  has  the  potential  to  stabilize  the  interface  of 
commercial  products  with  their  shorter  product  life  cycles. 

As  this  paper  is  being  written,  Lockheed  Martin  TDS  is 
finalizing  plans  to  introduce  the  switch  as  a  commercial 
product. 
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Figure  7.  Topologies  for  SCI  Bandwidth  Scalability 

The  switch  is  illustrated  in  Figure  8  as  part  of  a  Scalable  interfaces.  Lockheed  Martin  TDS  has  also  designed  a  Versa 

Multi-Processing  System  (SMPS).  It  is  a  multistage  switch  Module  Eurocard  (VME)/SCI  gateway  to  serve  as  a  bridge 

designed  with  layered  redundant  paths  for  fault  tolerance  and  between  VME/64  and  SCI  protocol.  The  VME/SCI  gateway 

special  features  to  reduce  the  blocking  normally  associated  shown  in  Figure  8  allows  the  SMPS  to  use  legacy  building 

with  multistage  switches.  The  switch  is  shown  attached  to  blocks,  for  example,  VME  graphics  cards. 

COTS  SuperSPARC™  processing  boards  with  SCI 
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Figure  8.  Prototype  SCI-Based  Scalable  Multi-Processor  System  (SMPS) 


To  realize  the  full  benefits  of  COTS  products,  the  defense 
industry  must  also  become  involved  in  software  standards  for 
open  systems.  Lockheed  Martin  continues  to  be  involved  in 
the  formulation  of  the  Portable  Operating  System  Interface 
for  Computer  Environment  Standards  (POSIX  -  IEEE 
1003.1).  More  reeently  we  have  begun  working  with  the  U.S. 
DoD  Open  System  Joint  Task  Force  (OSJTF)  to  evaluate,  and 
if  deemed  feasible,  promote  the  efforts  of  a  commercial 
working  group  for  military  real-time  applications.  The 


objective  of  the  working  group  is  to  develop  a  Uniform 
Device  Interface  (UDI)  enabling  input/output  (I/O)  device 
drivers  to  be  ported  between  COTS  operating  systems.  A 
prototype,  proof-of-concept  UDI  environment  is  currently 
under  development  (see  Figure  9).  Lockheed  Martin  will 
supply  a  metalanguage  description  for  the  SCI  protocol, 
library  functions,  and  a  portable  SCI  driver  for  the  UDI 
Environment. 
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Figure  9.  Open  System  Activities  Supporting  P^l 


Figure  9  also  illustrates  other  activities  in  which  the  defense 
industry  has  been  and  needs  to  be  involved.  For  example, 
POSIX  standards  are  currently  being  defined  by  members  of 
commercial  and  defense  industry.  However,  the  decision  to 
utilize  POSIX-compliant  operating  systems  for  aerospace 
mission  systems  will  be  determined  by  real-time  requirements 
and  the  maturity  of  POSIX  operating  systems.  To  provide 
alternatives  compatible  with  future  COTS  products, 

Lockheed  Martin  TDS  has  recommended  that  OSJTF 
integrate  the  UDI  Environment  with  Ada  stand-alone  run¬ 
time  environments  as  shown.  Subsequently,  Ada  stand-alone 
run-time  environments  with  POSIX  compatible  COTS 
portable  drivers  can  be  used  with  next  generation  aerospace 
mission  systems. 

6.0  CONCLUSIONS 

The  authors  of  this  paper  have  concluded  that  COTS  has 
'‘joined  the  military”  and  will  become  an  increasingly  larger 
part  of  aerospace  mission  systems  for  at  least  three  reasons: 

1 .  COTS  provides  greater  capability  at  a  lower  cost 

2.  COTS  supports  continuous  and  graceful  insertion  of 
technology 

3.  COTS  provides  scalable  system  growth. 

However,  all  of  the  above  reasons  directly  contribute  to  the 
shortened  life  cycle  of  COTS  products.  The  shortened  life 
cycle  will  require  the  use  of  P^I  and  the  adoption  of  open 
system  architectures  for  military  systems.  Standard  hardware 
and  software  interfaces  are  the  key  to  open  systems. 

Use  of  COTS-based  open  systems,  together  with  P^I,  requires 
1 )  the  selection  of  an  interconnect  that  satisfies  commercial 
hard  ware/ soft  ware  trends,  2)  the  phased  integration  of  legacy 
approaches  with  proven  new  approaches,  and  3)  the 
development  of  components  that  enable  the  integration  of 
legacy  components  with  newer  technology.  The  defense 
industry  must  participate  and  invest  in  the  development  of  all 
three. 

Combining  a  COTS-based  open  system  approach  with  P^I 
was  illustrated  with  activities  currently  underway  at  Lockheed 
Martin  Tactical  Defense  Systems.  Working  with  both 
defense  and  commercial  technology  leaders,  Lockheed  Martin 
adopted  the  use  of  the  IEEE  1 596  Scalable  Coherent  Interface 
for  next  generation  aerospace  mission  systems.  The  protocol 


supports  evolving  software  trends  (multiprocessing  shared 
memory),  but  will  also  support  message-oriented  legacy 
systems. 

To  improve  the  SCI  interconnect  for  defense  applications,  a 
scalable,  low-latency,  fault-tolerant  SCI  switch  was 
developed.  Switch  development  was  followed  by  the 
development  of  a  VME/SCI  bridge  enabling  legacy  systems 
to  work  with  COTS  SCI  products.  Plans  are  underway  to 
make  the  SCI  switeh  available  in  the  commercial  market. 

This  will  provide  military  systems  with  the  economy  of  scale, 
life  cycle  cost  benefits  and  COTS  product  stability  required 
for  P^I.  Aceess  to  portable  SCI  software  drivers  is 
simultaneously  being  made  available  through  the  Uniform 
Driver  Interface  commercial  working  group  and  the  U.S. 
DoD’s  Open  System  Joint  Task  Force. 

This  paper  provides  only  an  introduction  to  COTS 
capabilities/issues.  Clearly,  we  could  only  scratch  the 
surface.  P^I  will  require  change  to  the  acquisition  processes 
including  certification  and  qualification.  This  in  turn  will 
require  the  defense  industry  to  better  understand 
environmental  requirements  and  the  limitations  of  COTS 
components  in  the  military. 
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1.0  SUMMARY.  Due  to  downsizing  of  the 
U.S.  defense  budget,  Department  of  Defense 
(DoD)  does  not  have  the  resources  to  “go  it 
alone”  anymore.  This  situation  warrants  closer 
cooperation  among  the  DoD  services,  the 
industrial  base  and  our  allies.  There  is  muph  to 
be  gained  from  the  wealth  of  technology 
available  from  the  commercial  sector,  especially 
in  electronics  for  telecommunications, 
computing,  display,  sensing  and  signal 
processing.  For  these  reasons,  among  others, 
recent  DoD  policies  have  placed  emphasis  on 
performance  specifications  and  standards  as 
opposed  to  using  military  specifications  and 
standards.  The  DoD  open  systems  initiative 
supports  this  new  emphasis  and  the  five 
“pillars”  in  transforming  acquisition  as 
delineated  by  the  Honorable  Paul  Kaminski, 
Under  Secretary  of  Defense  for  Acquisition  and 
Technology: 

(1)  Right  Size  Our  Infrastructure 

(2)  Reduce  Cost  of  Weapon  System 

Ownership 

(3)  Implement  Acquisition  Reform 

(4)  Leverage  the  National  Industrial  Base 

(5)  Leverage  Our  Allies'  Industrial  Base 

The  use  of  an  open  systems  approach  is 
motivated  largely  by  the  need  (and  the 
opportunity)  to  reduce  the  cost  of  ownership  of 
weapons  systems.  Open  systems  are  not  the 
objective,  rather  an  open  systems  approach  is  a 
means  for  program  managers  and  their 
integrated  product  teams  to  achieve  their 
fundamental  program  objectives  of  lower  life 
cycle  cost  and  improved  performance. 


Open  systems  electronics  apphcations  include 
mechanical  form  factors,  power  supplies, 
radio/intermediate  frequency  (RF/IF)  interfaces, 
and  thermal  management. 

An  open  systems  approach  uses  widely 
accepted,  public  consensus  standards,  that  any 
vendor  can  use  as  the  basis  for  system  design. 
Having  already  proven  itself  in  commercial 
telecommunications  and  confuting,  an  open 
systems  approach  has  been  used  successfully  by 
the  military  Command,  Control, 
Communications,  Computers  and  Intelhgence 
(C‘*I)  community  and  is  now  being  implemented 
in  the  weapons  systems  acquisition  community 
through  the  Open  Systems  Joint  Task  Force 
(OS-JTF).  This  paper  will  focus  on  the  OS-JTF 
efforts  to  develop  the  foundations  of  open 
systems  for  weapon  systems  electronics. 

2.0  BACKGROUND. 

2.1  Open  Systems  Policy.  On  29  November 
1994,  Dr.  Kaminski  signed  a  policy 
memorandum  promulgating  the  open  system 
approach  for  acquisition  of  weapons  system 
electronics  [1].  The  policy  apphes  to  new 
developments  as  well  as  modifications  to 
existing  weapons  systems  and  platforms. 
Although  weapons  systems  must  interface  with 
C'*!  systems,  the  pohcy  does  not  apply  directly 
to  C'^I  systems,  communications  networks,  nor 
non-real-time  data  processing  functions  covered 
by  other  policy  letters.  The  scope  of  system 
and  subsystems  elements  for  which  the  weapons 
systems  electronics  policy  applies  includes 
hardware,  software,  tools,  architecture,  and 
electrical,  mechanical,  and  thermal  interfaces. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  "Advanced  Architectures  for  Aerospace 
Mission  Systems",  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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2.2  Formation  of  the  Open  Systems  Joint 
Task  Force  (OS-JTF).  Dr.  Kaminski’s  open 
systems  policy  chartered  the  OS-JTF.  The  OS- 
JTF’s  vision  is  to  “estabhsh  in  DoD  an  open 
system  approach  as  the  foundation  for  all 
weapons  systems  acquisitions  in  order  to  lower 
life  cycle  costs  and  improve  weapons  system 
performance.”  The  Task  Force  is  chartered  for 
approximately  four  years.  The  ultimate 
responsibility  for  execution  of  open  systems 
acquisitions  is  vested  in  each  Service’s 
acquisition  community. 

The  OS-JTF  staff  consists  of  a  Director,  a 
haison  from  the  Defense  Information  Systems 
Agency,  a  DoD  program  analyst, 
representatives  from  each  of  the  three  military 
services  and  support  contractors.  The  Director 
reports  directly  to  the  Principal  Deputy  Under 
Secretary  of  Defense  (Acquisition  & 
Technology),  the  Honorable  R.  Noel 
Longuemare. 

To  achieve  the  open  systems  vision,  the  Task 
Force  endeavors  to: 

□  Assure  that  members  of  the  DoD 
acquisition  workforce,  m  particular  program 
managers  and  lead  engineers,  understand 
the  open  systems  pohcy  and  know  how  to 
implement  it; 

□  Assure  that  electronics  industry  and 
standards  bodies  are  aware  of  the  pohcy  and 
the  new  opportunities  it  presents; 

□  Identify  opportunities  for  implementing 
open  systems  architectures; 

□  Share  widely  the  lessons  learned  in  open 
systems  implementations; 

□  Estabhsh  key  interface  standards  for  use  in 
weapons  systems  in  the  DoD;  and 

□  Institutionalize  the  open  systems  approach 
across  DoD  so  that  the  Task  Force  is  no 
longer  required. 

Anticipated  benefrts  of  an  open  systems 
approach  are: 

□  Reduced  life  cycle  costs  for  weapons 
systems; 


□  Improved  performance  with  greater  intra¬ 
op  erabihty; 

□  Technology  transparency  for  rapid 
upgrades; 

□  Improved  interop  erabihty  for  j  oint  and 
alhed  warfightmg; 

□  Closer  cooperation  between  commercial 
and  mihtary  electronics  industries;  and 

□  Improved  international  competitiveness  of 
theU.S.  electronics  industry. 

3.0  THE  MOVE  TO  OPEN  SYSTEMS. 

3.1  InitiaUy,  most  open  systems  discussions 
were  narrowly  focused  in  one  dimension,  i.e., 
along  the  lines  of  simply  being  “closed”  versus 
“open”  systems.  Closed  systems  were  regarded 
to  be  proprietary,  secret,  or  patented,  while 
open  systems  were  based  on  standards  which 
were  agreed  to  and  pubhshed  by  an  accredited, 
consensus-based  group.  Over  the  past  eighteen 
months,  the  Task  Force  has  articulated  a  much 
broader  view,  aUowing  for  a  multi- dimensional 
model  of  open  systems  depicted  in  Figure  1. 

The  first  of  several  additional  dimensions  is 
“market  acceptance”.  For  a  system  to  be  truly 
open,  it  must  have  a  broad  market  base  as  it 
does  httle  good  to  have  open  system  standards 
and  specifications  which  are  not  supported  by 
products.  The  desired  operating  regime  for 
weapons  systems  acquisitions  of  the  future  is 
one  with  many  supphers,  many  customers,  long 
life  architectures  and  readily  available 
technology  upgrades. 

3.2  Several  other  interrelated  open  systems 
dimensions  are  worthy  of  note:  time;  coverage 
or  completeness;  performance;  and  price.  The 
outlook  for  open  systems  is  not  static— systems 
may  migrate  toward  openness  over  time  as  a 
standard  gains  market  acceptance  or  as  the 
interface  is  made  pubhc  in  order  to  increase  the 
market  base.  Specific  open  systems  standards 
and  interfaces  may  have  varying  degrees  of 
apphcabihty  to  weapons  systems.  Weapons 
systems  must  generally  perform  in  real-time  and 
in  a  deterministic  manner.  Extensions  or 
adaptations  to  open  standards,  while  not 
generally  desired,  may  be  required  to  meet  the 
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unique  needs  of  a  particular  weapons  system 
For  example,  the  design  of  tactical  aircraft 
places  a  premium  on  weight,  volume  and 
environmental  requirements,  and  therefore  may 
require  a  different  set  of  trade-offs  in 
performance  with  respect  to  open  system 
standards. 

4.0  THE  OPEN  SYSTEMS  APPROACH. 

An  open  systems  approach  is  a  business 
approach  for  developing  affordable  weapons 
systems.  This  approach  chooses  from  among 
open  system,  de  facto,  and  Government 
specifications  and  standards,  and  commercial 
practices,  products  and  interface  standards  to 
provide  quick  access  to  technologies  that 
maximize  combat  effectiveness  under  a  given 
cost  constraint  [2].  The  iterative  nature  of  the 
open  systems  approach  is  depicted  in  Figure  2 
and  is  discussed  in  the  following  paragraphs. 

4.1  The  Architectures.  The  open  systems 
approach  advocated  by  the  OS-JTF  is  based,  in 
part,  on  a  concept  of  describing  the  electronic 
portion  of  weapons  systems  using  a  standards 
based  architecture.  This  architecture  consists  of 
a  technical  reference  model  and  the  standards 
that  describe  the  interfaces  and  services 
between  the  components.  This  has  been  defined 
as  a  “technical  architecture”  and  may  be 
compared  to  a  set  of  budding  codes.  These 
budding  codes  help  industry  estabhsh  and 
maintain  an  orderly  and  competitive 
marketplace.  The  “technical  architecture”  is 
distinguished  from  the  “operational 
architecture”  which  is  defined  by  the  weapons 
system  user  and  a  “system  architecture”  which 
is  the  particular  system  designed  to  meet  a 
particular  performance  requirement  with 
specific  hardware  and  software  based  on  the 
technical  architecture. 

4.2  Open  Systems  Engineering  Process.  The 
traditional  systems  engineering  process  must  be 
modified  as  depicted  in  Figure  2  to 
accommodate  the  changes  brought  about  by  the 
open  systems  process.  The  DoD  and  industry 
must  work  together  within  an  open  systems 


framework  to  select  and  apply  the  appropriate 
weapons  systems  standards.  This  process  must 
consider  the  entire  weapons  system  life  cycle. 

4.2.1  Development  and  Selection  of 
Standards.  Just  as  with  building  codes, 
industry  has  the  primary  role  of  defining, 
developing  and  maintaining  the  standards  that 
will  form  the  basis  for  weapons  system 
electronics.  These  standards  must  address  both 
hardware  and  software  and  include  the  non¬ 
digital  areas  such  as  packaging  (physical 
interface),  power,  cooling  and  analog  signals. 

Although  industry  has  a  dominant  role,  the 
DoD  has  an  essential  part  to  play  as  well.  DoD 
customers  must  help  industry  define  the  unique 
weapons  system  requirements.  To  the  extent 
possible,  it  is  helpful  for  the  DoD  customers  to 
speak  with  one  voice  and  appropriately  narrow 
some  design  standards  to  allow  industry  to 
respond  efiBciently  to  our  needs.  A  model  for 
this  customer  consortium  is  the  recent  work  of 
the  automobile  industry  to  jointly  define  key 
standards  for  the  products  provided  by  their 
common  suppher  base.  In  this  sense,  the  DoD 
must  select  or  recognize  the  interface  standards 
to  be  used  for  our  products. 

Selection  of  standards  agreed  to  by  accredited, 
consensus-based  standards  bodies  (i.e.  open 
standards),  and  in  widespread  use,  is  highly 
desirable.  They  frequently  have  a  broad  base  of 
suppher  and  customer  acceptance,  are  mature 
technically  and  are  chosen  fairly.  Some 
proprietary  standards  have  become  de  facto 
standards  through  widespread  market 
acceptance.  Because  of  our  desire  to  build 
weapons  systems  based  on  commercial 
electronics  technology  and  the  industrial  base, 
both  consensus  based  and  de  facto  standards 
are  critical  to  us.  For  that  reason,  the  OS-JTF 
has  chartered  the  Committee  on  Open 
Electronics  Standards  (COES)  to  harmonize  the 
many  on-going  architecture  efforts  and  extend 
the  Joint  Technical  Architecture  [3]  to  include 
weapon  systems.  COES  will  not  develop  its 
own  standards  but  will  identify  weapon  system 
domain  stakeholders  who  will  designate  open 
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standards  and  develop  domain  technical 
architectures.  These  standards  will  be  selected 
based  on  an  assessment  of  both  government 
and  industry  standardization  efforts  to  focus  on 
specific  weapons  systems  community  needs. 

The  current  domains  under  consideration  by 
COES  are  depicted  in  Figure  3. 

4.2.2  Application  of  Standards.  The 
standards  applied  to  create  a  system 
architecture  must  be  based  on  performance 
requirements  and  the  business  case  for  the 
acquisition  strategy.  Many  factors  must  be 
weighed  in  the  decisions  of  what  standards 
should  be  applied.  These  factors  include:  the 
support  strategy  (maintenance  and  repair  and 
spares  procurement  approaches),  the  strategy 
for  evolution  and  upgrade  of  the  product  with 
regard  for  life  of  the  technology,  risk 
management,  market  research  and  life- cycle 
cost. 

The  application  of  standards  may  vary  for 
different  portions  of  the  system.  The 
government  maintains  configuration  control 
above  this  level  of  application.  Below  this  level, 
industry  must  be  given  maximum  latitude  to 
make  design  decisions  without  mterference. 

The  contractor  must  retain  rights  to  his  designs 
and  requirements  for  design  disclosure  should 
be  minimized.  This  will  allow  contractors  to 
exploit  innovation,  process  improvement  and 
new  technology  for  their  benefit  as  well  as  that 
of  DoD.  Each  program  should  choose  how  to 
apply  these  architectural  standards  or  building 
codes  for  maximum  benefit.  The  product 
descriptions  that  make  up  the  system 
architecture  and  which  include  the  interface, 
interop erabihty  and  performance  requirements 
are  also  called  Form,  Fit,  Function  and  Interface 
(F^I).  F^I  acquisition  is  a  strategy  for  dealing 
with  obsolescence,  diminishing  manufacturing 
sources,  acquisition  workforce  reductions,  and 
implementing  acquisition  reform. 

Domam  product  lines  contain  a  group  of 
building  blocks  (products,  services,  tools  and 
processes)  to  constrain  or  enhance  systems 


engineering  process  to  meet  specialized  domain 
needs. 

The  level  of  interfaces  to  be  defined  is 
dependent  upon  the  specific  product  or  system 
to  be  acquired  and  supported.  Examples  include 
an  entire  avionics  suite,  a  major  avionics 
subsystem,  and  a  module  within  an  avionics 
fimction.  These  key  interface  definitions 
provide  the  framework  for  an  open  system 
approach.  The  architecture  should  define  an 
“atomic”  level.  Interfaces  at  this  level  and 
above  should  conform  to  the  defined  standards. 
Design  below  the  “atomic”  level  will  be  under 
the  control  of  the  supphers.  The  “atomic”  level 
should  coincide  with  the  repairable  level.  There 
should  be  no  organic  repair  below  the  “atomic” 
level.  The  choice  of  the  “atomic”  level  and  the 
associated  standards  should  be  based  on  the 
anticipated  life  cycle  cost,  performance,  risk 
and  business  considerations. 

5.0  IMPLEMENTATION 

5.1  Open  Systems  Training.  The  Task  Force 
has  coordinated  the  development  of  several 
open  systems  educational  products  to  increase 
the  DoD  acquisition  workforce’s  knowledge  of 
issues  and  practices.  First,  a  basic  course  has 
been  developed  by  the  Software  Engineering 
Institute  (SEI)  of  Carnegie  Mellon  University, 
entitled  “Open  Systems:  Promises  and  Pitfalls”. 
This  2-1/2  day  basic  course  is  given  periodically 
throughout  the  year.  Second,  the  Task  Force 
has  sponsored  the  development  of  a  four-hour 
executive  presentation  for  senior  acquisition 
officials,  program  managers  and  their  fimctional 
staff".  These  efforts  will  eventually  be 
transferred  to  the  Defense  Acquisition 
University  and  the  Services  for  on-gomg 
training  of  the  acquisition  workforce. 

5.2  Standards  Activities.  The  OS-JTF,  in 
conjunction  with  numerous  standards  bodies, 
government  and  contractor  efforts,  is 
sponsoring  investigations  of  a  number  of 
standards  activities.  These  include  the 
definition  of  Ada  language  bindings  (X/Open 
Transport  Interface  and  Sockets),  Real-Time 
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Extension  of  Portable  Operating  System  for 
Unix  (POSIX),  interconnect  technology  trade 
studies  (Scaleable  Coherent  Interface/Real- 
Time,  Asynchronous  Transfer  Mode  and  Fibre 
Channel),  radio  frequency  standards  (Integrated 
Sensor  System)  and  a  technical  reference  model 
(Generic  Open  Architecture). 

5.3  Demonstration  Programs.  The  Air  Force 
Open  System  Implementation  Plan  [4]  fostered 
the  notion  that  a  series  of  demonstration 
programs  would  be  effective  in  accelerating  the 
acceptance  of  open  systems  approaches.  On  15 
February  1996,  Mr  Longuemare  designated  two 
avionics  modernization  efforts  as  open  systems 
demonstration  programs:  the  U.S.  Marine 
Corps  AV-8B  Open  System  Core  Avionics 
Requirements  (OSCAR)  and  the  U.S.  Air  Force 
F-15  Multi-Purpose  Display  Processor,  shown 
in  Figures  4  and  5.  These  efforts  were 
identified  by  their  respective  Program  Executive 
Officers  as  having  significant  open  systems 
potential. 

The  demonstrations  are  currently  being  planned 
and  executed  through  a  Joint  Steering 
Committee  consisting  of  members  from  the 
cognizant  program  offices,  the  OS-JTF  and 
McDonnell  Douglas  Aerospace  and  its 
suppliers.  A  major  objective  of  the 
demonstration  programs  is  to  quantify  the 
benefits  of  the  open  systems  approach  in 
meeting  specific  weapons  systems 
requirements.  The  demonstration  programs 
will  not  only  focus  on  technical  issues,  but  will 
seek  to  resolve  the  many  business  issues  facing 
the  DoD  and  industry  as  we  move  to  open 
system  acquisitions. 

Closely  related  to  the  above  demonstrations  is 
an  Open  Systems  Ada  Technology  (OSAT) 
demonstration  jointly  ftmded  by  the  Ada  Joint 
Program  Office,  the  Joint  Strike  Fighter 
Program  Office  and  the  OS-JTF.  This  effort 
will  prove  the  feasibility  of  using  Ada95  in  a 
real-time  apphcation,  a  Runge-Kutta  algorithm 
hosted  in  a  PowerPC  processor  installed  in  an 
AV-8B.  The  flight  demonstration  is  scheduled 
for  December  1996. 


6.0  CONCLUSION.  Creation  of  a  technical 
architecture  and  its  broad  apphcation  to  open 
systems  wih  ahow  industry  to  develop 
competing  products  that  meet  our  needs.  They 
will  be  able  to  innovate  and  apply  new 
technology  and  processes  to  improve 
performance  and  reduce  costs  within  this 
planning  structure.  Program  managers  will  be 
able  to  take  advantage  of  electronics 
technology  developed  for  the  private  sector, 
increased  competition  and  product  upgrades 
based  on  F^I  product  descriptions  and  long- 
lived  architectures  rather  than  sole  source 
supphers.  We  wih  also  be  better  able  to  avoid 
obsolescence  issues  by  being  better  positioned 
to  apply  new  technology  to  replace  obsolete 
and  no  longer  available  or  supportable 
technology.  The  open  system  approach 
provides  new  opportunities  for  life  cycle 
support  of  DoD  weapon  systems.  The  move 
toward  open  systems  has  begim  in  earnest  with 
the  release  of  a  DoD  pohcy,  development  of 
training  courses  for  the  acquisition  workforce, 
estabhshment  of  some  demonstration  programs, 
and  pubhcation  of  Component/Service 
Deployment  Plans.  Updated  information 
regarding  the  progress  toward  open  systems  m 
DoD  is  pubhshed  periodically  on  the  Task 
Force’s  World  Wide  Web  Home  Page  [5]. 

How  far  DoD  moves  along  the  path  to  true 
openness  for  affordable  weapons  systems  m  the 
future  depends,  in  part,  on  the  success  of  the 
demonstration  programs,  communication  of 
lessons  learned  and  the  willingness  of  the 
workforce  to  embrace  these  emerging  concepts. 
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MODULAR  AVIONICS  SYSTEM  ARCHITECTURE  DEFINITION  IN  THE  EUCLID  RESEARCH  AND  TECHNOLOGY 

PROGRAMME  4.1:  METHODOLOGY  AND  RESULTS 
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Alenia  Aeronautica 
Statailimento  Caselle  Nord 
Strada  Privata,  10072  Caselle  Torinese,  Italy 


SUMMARY 

The  European  Cooperation  for  Long  Term  in 
Defense  (EUCLID)  Research  and  Technology 
Programme  (RTP)  4.1  "Modular  Avionic 
Harmonization  Study"  (Ref.  1)  is  a  joint 
programme  carried  out  by  France,  Germany, 
Italy,  Netherlands,  Spain  and  United 
Kingdom,  aiming  to  harmonize  modular 
avionic  concepts  among  the  aforementioned 
nations,  thus  preparing  a  common  European 
basis  for  the  future  development  of 
modular  avionics  platforms,  taking  as 
reference  the  2005/2010  in  service  date 
time  frame. 

The  work  has  been  developed  through  five 
work  packages,  dedicated  respectively  to 
General  Requirements  for  Modular  Avionics, 
System  Architecture  Definition  and  Risk 
Assessment,  Technolo^  Programmes,  Modular 
Avionics  Support  Facilities, 

Identification  of  a  Roadmap  for  Modular 
Avionics . 

This  paper  presents  an  overview  of  the 
methodology  that  has  been  adopted  to  come 
to  the  definition  of  a  modular  avionic 
system  architecture  which  is  capable  to 
satisfy  a  defined  set  of  functional 
requirements,  in  presence  of  technical 
constraints  of  various'  nature  resulting 
from  technology  assessments  carried  out 
during  the  programme.  The  paper  discusses 
the  following  subjects: 

+  The  different  functional  areas  to  be 
covered  by  an  avionic  system  tailored  on 
an  envelope  of  operational  requirements. 

*  The  different  categories  of 
functional/physical  elements  which 
compose  the  modular  system. 

*  Those  requirements,  among  the  set  of 
driving  functional  requirements  taken  as 
reference  in  the  course  of  the  study, 
whose  impact  has  been  so  relevant  to 
drive  or  condition  the  architectural 
study . 

*  Technical  requirements  and  constraints 
associated  to  the  physical  elements, 
having  a  direct  impact  on  the  system 
architecture  model. 

*  The  basic  characteristics  and  an  outline 
of  the  proposed  architectural  model,  how 
it  has  proceeded  from  the  above 
functional /technical  requirements,  and 
how  it  incorporates  important  features, 
such  as  an  adequate  capability  to 
tolerate  faults  by  reconfiguration  and 
to  perform  data  fusion  at  various 
levels . 

*  Limits  of  the  architectural  study 
carried  out . 


1.  INTRODUCTION 

Integrated  modular  avionics  architectures 
are  expected  to  feature  substantial 
advantages,  with  respect  to  current 
avionics,  from  both  the  life  cycle  cost 
and  the  performances  viewpoint.  While  it 
is  almost  taken  for  granted  that  modular 
architectures  will  equip  next  generation 
aircrafts,  the  attention  is  focused  also 
on  the  possibility  of  modular  upgrades. 
Modernization  of  existing  aircrafts  with  a 
complete  modular  suite  should  be 
considered  feasible  once  constraints,  such 
as  available  physical  space  and  interfaces 
with  the  electrical  generation  system,  are 
met.  On  the  other  hand,  the  possibility  of 
retaining  part  of  the  existing  avionic 
system  should  be  evaluated  more  carefully, 
as  for  feasibility  and  effectiveness  of 
the  proposed  solutions. 

In  order  to  implement  modular  avionics  in 
a  project,  whether  centered  on  a  new 
target  platform  or  on  upgrades  of  current 
ones,  research  activities  have  to  be 
carried  out  in  different  directions,  and, 
having  to  cope  with  the  availability  of 
limited  resources,  with  different 
priorities . 

In  the  USA  the  concept  has  been  developed 
by  programmes  such  as  PAVE  PILLAR,  and, 
more  recently,  PAVE  PACE.  The  concepts 
defined  in  PAVE  PILLAR  have  been  already 
transitioned  to  the  F-22  Advanced  Tactical 
Fighter  and  RAH-66  Helicopter  (Ref.  2). 
European  Nations  have  approached  the 
subject  with  national  research  programmes 
and  joint  research  programmes,  such  as  the 
Allied  Standards  Avionic  Architecture 
Council  (ASAAC)  phase  1  and  2,  and  the 
programmes  incorporated  in  the  Common 
European  Priority  Area  (CEPA)  4  within  the 
EUCLID  frame.  It  should  be  underlined  that 
ASAAC  is  not  strictly  speaking  a  European 
programme,  as  phase  1  has  seen  the 
participation  of  France  Germany,  United 
Kingdom  and  the  USA. 

As  stated  in  the  summary,  this  paper  is 
focused  on  the  portion  of  work  that, 
within  RTP4.1,  has  been  developed  at30ut 
the  topic  of  system  architecture 
definition.  For  completeness,  it  is 
nevertheless  necessary  to  briefly  report 
the  overall  structure  of  the  programme. 

2.  OVERALL  STRUCTURE  OF  THE  PROGRAMME 

RTP4.1  has  been  the  first  programme 
carried  out  in  the  CEPA  4  "Modular 
Avionics",  leaded  by  Germany  within  the 
EUCLID  frame,  with  participating  nations 
France,  Germany,  Italy,  Netherlands, 

Spain,  United  Kingdom.  It  began  in 
February  '94,  and  is  technically  concluded 
while  this  paper  is  being  written. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems’’,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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The  work  has  been  developed  through  the 
following  work  packages  (WP) : 

WPl :  General  Requirements  for  Modular 
Avionics ,  mainly  devoted  to  the  definition 
of  general  mission  requirements  and 
operational  aspects  for  different  airborne 
platforms . 

WP2 :  System  Architecture  Definition  and 
Risk  Assessment,  aimed  to  the  definition 
of  a  suitable  system  architecture  proposal 
for  integrated  modular  avionics.  This 
paper  is  focused  on  this  work  package. 

WP3 :  Technology  Programmes,  devoted  to  the 
study  of  technology  areas  deemed  essential 
for  modular  avionics  system  development. 
The  examined  technology  domains  have  been 
primarily  those  affecting  the  processing 
digital  core  of  the  system  (Networks, 
Packaging,  Data/Signal  Processing, 
Software) ,  while  external  areas  (Radio 
Frequency  (RF) ,  Electro  Optical  (EO) 
sensors)  have  been  considered  at  the  level 
necessary  for  core  definition. 

WP4 :  Modular  Avionic  Support  Facilities, 
dedicated  to  the  study  of  Integrated 
Project  Support  Environment  and 
HW/SW/System  Development  tools/facilities. 

WPS :  Identification  of  a  Roadmap  for 
Modular  Avionics,  planning  a  way  ahead  for 
further  development  of  modular  avionics 
based  on  European  technologies. 

3.  BOUNDARIES  OF  THE  ARCHITECTURAL  STUDY 
AND  ACTIVITY  FLOW 

The  following  consideration  will  help  in 
looking  at  the  results  of  the  study  with 
the  correct  perspective. 

•  In  defining  the  main  building  blocks  and 
Europe  based  technologies  for 
application  in  a  modular  avionic 
architecture,  the  study  has  taken  as 
reference  the  in-service  time  frame 
2005-  2010.  Roadmap  studies  have  finally 
suggested  as  feasible  an  in-service  date 
of  about  2015  for  a  new  fast  jet,  while 
a  nearer  time  frame  (2010)  can  be 
assumed  for  retrofit  programmes. 

•  No  attempt  has  been  made  in  trying  to 
define  the  complete  requirements  for  a 
specific  aircraft  or  helicopter.  This 
because  of  the  necessity  not  to 
specialize  the  study,  from  the 
beginning,  to  a  specific  platform  or  to 
an  exhaustive,  but  to  some  extent 
arbitrary,  set  of  operational 
requirements.  This  approach  seems 
correct  if  compared  with  important 
features  of  the  modular  approach: 
improved  adaptability  and  an  open 
architecture.  Mission  profiles  which,  in 
association  with  platform  types,  have 
been  considered,  and  whose  general 
requirements  have  been  described,  are: 

1 .  Air  to  Air 

2  .  Air  to  Ground 

3  .  Maritime 

4.  Intelligence  Gathering 

5 .  Surveillance 

6 .  Transport 

•  The  study  has  been  focused  on  the 
digital  core  of  the  system  (see  para.  4 


for  definition)  while  the  remainder  of 
the  system  has  been  mainly  considered 
with  regard  to  its  interfaces  with  the 
core.  As  PAVE  PACE  studies  indicate, 
great  advantages  are  promised  by  the 
extension  of  the  modular/integration 
concepts  toward  the  surviving  analog 
portion  of  the  sensors  set  (readers  not 
acquainted  with  the  new  sensor  concept 
implicit  in  integrated  modular  avionics 
will  find  more  detail  in  para  5.1  of 
this  paper) .  While  a  through  analysis  in 
this  direction  was  outside  the  scope  of 
the  study,  the  subject  has  been  taken  in 
account  with  a  twofold  strategy: 

1 . Carry  out  a  preliminary  examination  of 
Radar,  Communication  /  Navigation  / 
Identification  (CNI)  and  EO  sensor 
front-ends,  highlighting  commonalities 
and  possible  analog  module  sets.  The 
result  can  constitute  the  starting  point 
for  possible  dedicated  future  activities 

2 . Indicate  architectural  alternatives  and 
technology  solutions  for  the  analog 
sensor  /  digital  core  interface  which 
are  open  to  the  evolution  toward  the 
sensor  integration  area. 

•  Safety  critical  functions  have  been 
considered  external  to  the  avionic 
system  core  (see  para.  5.5).  A  Vehicle  / 
Stores  Control  Block  has  been  interfaced 
to  the  core,  but  not  furtherly  analyzed. 

The  pictorial  description  of  Fig.  1  will 
help  in  clarifying  the  methodology  applied 
for  the  architectural  study,  creating  a 
correspondence  between  the  flow  of 
activities  and  the  topics  discussed  in  the 
following  paragraphs. 

4.  RATIONALE  FOR  INTEGRATED  MODULAR 

AVIONICS;  COMMONALITIES  AND  FUNCTIONAL 
PARTITIONING 

In  order  to  carry  out  an  integration  of  a 
set  of  functions,  commonalities  must  be 
identified  among  them.  Common  elements 
will  then  be  realized  with  modular 
building  blocks  (hardware  and  software) , 
and  will  be  combined  with  non-common 
elements  and  connection  facilities  in  a 
system  architecture.  The  approach,  if 
properly  applied,  will  bring  those 
advantages  in  terms  of  Life  Cycle  Costs 
and  performances  which  have  been  pointed 
out  many  times  in  literature,  and  justify 
the  effort  of  the  avionic  community  in 
pursuing  integrated  modular  architectures. 
According  to  this  philosophy,  we  should 
try  to  describe  the  system  without  be 
bounded  to  traditional  physical  blocks  or 
subsystems.  We  therefore  start  noticing 
how  the  most  general  avionic  system  is  a 
collection  of  Generators,  Processors  and 
Utilizers,  connected  by  means  of  Channels. 
Information  is  originated,  processed  and 
supplied,  flowing  through  logical 
successive  stages,  exploiting  services 
supplied  by  system  elements .  Each  avionic 
function  will  relay  at  least  on  a  subset 
of  these  elements.  A  generic  chain  of 
system  elements  is  shown  in  Fig. 2 
particularized,  as  for  the  analog  stages, 
to  an  RF  application: 

•  Sensor  /  Emitter  Heads:  mechanical  / 
electrical  sensing  or  emitting  surfaces 
/  components. 
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•  Signal  Conditioning:  stage  receiving  and 
converting  the  sensed  signal,  or 
supplying  signals  in  forms  usable  by 
emitters.  As  for  RF  applications,  this 
stage  will  be  splitted  in  RF  and 
Intermediate  Frequency  (IF)  sub-stages. 

•  Pre-Processing :  essentially 
demodulation,  analog  to  digital  (A/D) 
conversion,  parallel/serial  conversion. 

These  stages  tend,  due  to  their  analog 
nature,  to  be  bounded  to  the  physical 
properties  of  the  specific  emission,  that 
is,  tend  to  be  application  specific. 
Prosecuting  our  analysis,  we  step  into  the 
digital  world.  Digitized  streams  of  data 
tend,  due  to  their  nature,  to  be  processed 
more  homogeneously  then  the  analog  signals 
which  originate  them.  The  following  system 
elements  can  be  individuated: 

•  Signal  Processing:  dedicated  to  extract 
information  from  raw,  high  rate  digital 
data,  by  means  of  operations  such  as 
filtering,  smoothing,  correlation, 
vector/matrix  operations,  averaging, 
thresolding,  Fourier  transforms,  etc... 

•  Data  Processing:  general  purpose 
processing,  acting  on  relatively  low 
data  rate,  but  performing  high  level 
complex  operations  (e.g.  moding,  threat 
classification,  database  management, 
etc . . . ) . 

•  Control  Processing:  control  of  system 
status  and  crew  interface.  Herein,  we 
will  define  it  comprehensive  of  the 
processing  required  for  graphic 
generation.  This  stage  will  therefore 
carry  out  complex  logical  operations  on 
a  huge  amount  of  status  and  control 
data,  and  also  image  manipulation  tas}<;s. 

Signal,  Data  and  Control  processing  are 
indeed  system  elements  for  which  a  great 
amount  of  commonal  presence  across  the 
various  functions  can  be  envisaged. 

This  results  more  clearly  briefly  listing 
the  main  functions  carried  out  by  the 
avionic  system  associated  to  a  generic 
weapon  platform  and  grouping  them  in 
macro-areas,  as  shown  in  Tab.  1.  The 
result  is  that,  together  with  sensors  and 
actuators  front-ends,  and  communication 
lin)cs,  a  cooperation  of  the  aforementioned 
digital  system  elements  is  sufficient  to 
carry  out  any  of  the  indicated 
subfunctions . 

Concluding  the  analysis  of  the  chain  of 
system  elements,  we  finally  find  the 
analog  front-ends  of  Displays  &  Controls 
and  Effectors  (synthesized  in  the  figure 
as  "Crew"),  any  computation  stage  at  this 
level  being  already  considered  before  as 
Control  Processing. 

The  avionics  system  "core"  is,  from  a 
functional  point  of  view,  the  collection 
of  Signal,  Data,  Control  Processing  system 
elements,  connected,  by  means  of  proper 
digital  communication  channels,  among  them 
and  toward  sensors  and  actuators  front- 
ends,  and  other  external  systems  if 
necessary.  This  concept  is  expressed  in 
Fig.  2,  which  highlights  the  processing 
elements  to  be  integrated  in  the  core, 
creating  a  so  called  Integrated  Digital 
Processing  Block  (IDPB) . 

The  system  elements  individuated  as 
components  of  the  digital  core  are  to  be 


regarded  as  functionalities,  to  be 
provided  by  physical  modular  units. 

5.  DRIVING  REQUIREMENTS  FOR  THE 
ARCHITECTURAL  STUDY 

The  starting  point  for  the  definition  of 
an  architectural  proposal  is  the 
availability  of  a  set  of  functional 
requirements  and  design  criteria  stated 
clearly,  in  a  form  which  can  steer  the 
architecture  topology  definition  ideally 
without  intermediate  translation  steps.  In 
their  turn,  functional  requirements  and 
general  design  criteria  are  to  be  derived 
from  an  analysis  of  more  general 
requirements  (Operational  and  Mission 
requirements)  together  with  Life  Cycle 
Costs  considerations. 

In  RTP4.1,  general  requirements  have  been 
defined  for  a  wide  set  of  missions  / 
platforms.  In  order  to  extract  from  these 
a  consistent  and  realistic  set  of 
functional  requirements,  an  analysis  has 
been  carried  out,  aimed  to  identify  the 
mission  profile,  among  those  described, 
that  deserves  to  be  considered  as  driver 
of  the  study.  The  Air  to  Ground  mission 
profile  has  been  selected  as  driver,  on 
the  base  of  the  following  considerations: 
it  features  more  demanding  sensors  and 
crew  interface  requirements  than  the  Air 
to  Air  one,  similar  to  Maritime  but  with 
higher  requirements  as  for  effectiveness 
of  crew  interface.  Transport  and 
Surveillance  missions  do  not  issue  top 
requirements.  Intelligence  Gathering, 
while  very  demanding  as  for  sensors  and 
crew  interface,  is  too  specific  to  be 
qualified  as  driver  for  the  study. 

Making  reference  to  Fig.  1,  considering: 

1. The  set  of  general  requirements 
associated  to  the  Air  to  Ground  mission 
profile . 

2.  Life  Cycle  Cost  general  criteria 
(synthetically  listed  in  Fig  1) . 

3 .  Commonalities  and  functional 
partitioning . 

4.  Cross  checks  with  those  results  of 
technology  studies  oriented  to  interface 
requirements  definition 

it  has  been  possible  to  come  to  the 
definition  of  a  set  of  functional 
requirements  and  design  criteria  to  be 
taken  as  drivers  for  the  architectural 
study.  These  are  listed  in  the  following, 
limitedly  to  those  aspects  which  have 
directly  conditioned  the  architectural 
study. 

5.1  Sensor  Control  Processing  and 
Interface  Requirements 

As  already  pointed  out,  the  maximization 
of  the  integration  of  digital  processing 
resources  in  the  system  core  is  bounded 
with  a  definite  simplification  of  sensors 
with  respect  to  current  implementations. 
Data  and  signal  processing  stages  which 
are  today  incorporated  in  the  sensor's 
LRUs  must  be  extracted  and  taken  at  core 
level.  This  concept  is  expressed  in  Fig.  2 
for  a  generic  radio  frequency  (RF) 
application.  One  result  is,  indeed,  having 
to  deal,  in  output  from  the  sensors,  with 
digitized  raw  signals  characterized  by 
much  higher  bandwidth  and  stronger  real 
time  /  latency  requirements  Chan  before. 
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Considering  the  set  of  sensors  which  have 
to  be  available  to  carry  out  the  Air  to 
Ground  mission  taken  as  reference,  we  find 
that,  from  the  requirements  point  of  view, 
they  can  be  almost  entirely  grouped  in 
four  macro-areas,  specifically  Multimode 
Radar,  EO,  Integrated  Defensive  Aids  and 
CNI .  Table  2  rGports_quantitative 
processing  and  interface  requirements  for 
these  sensor  areas.  In  reading  the  table, 
the  following  should  be  considered; 

•  The  unit  GFLOPS  indicates  a  number  of 
billion  of  floating  point  operations  per 
second,  and  is  considered,  relatively  to 
the  general  approach  that  is  possible  to 
apply  at  this  stage,  representative  for 
signal  processing  performances. 

•  The  unit  MIPS  indicates  the  number  of 
million  of  instructions  per  second, 
pertaining  to  an  averagely 
representative  instruction  set.  It  is 
used  to  quote  data  processing 
requirements . 

•  The  output  data  rate  refers  to  the  flow 
of  digitized  raw  data  to  be  transferred 
from  the  sensor  area  to  the  core 
processing,  and  is  expressed  in  billion 
of  bit  per  second  (Gbit/s) . 

•  The  iteration  time  refers  to  the 
sampling  rate  of  the  digitized  data  to 
be  processed  in  the  core. 

•  The  figures  in  the  table  are 
projections,  10-15  years  ahead,  of 
values  valid  for  present  sensors,  and 
should  be  considered  as  estimates. 

5.2  Mission  /  System  Control  Processing 
Requirements 

This  functional  layer  will  gather,  in 
addition  to  improved  traditional  avionic 
functions  carrying  out  navigation,  weapon 
aiming,  system  moding,  initialization, 
diagnostics  tasks,  new  features  definitely 
characterizing  the  next  generation  of 
military  avionics,  dealing  with  data 
fusion.  Mission  requirements  call  in  fact 
for  an  high  level  of  integration  as  for 
information  presented  to  the  crew, 
especially  for  a  platform  like  the  one 
selected  as  driver  of  the  study. 

It  is  possible  to  distinguish  between  two 
level  of  data  fusion: 

Fusion  of  processed  information:  data 
outcoming  from  signal  /  data  processing 
stages,  carrying  meaningful  information 
about  different  mission  aspects,  can  be 
furtherly  processed  in  order  to  extract 
from  them  a  new  set  of  "fused",  improved 
information.  Such  a  process  can  be 
applied,  for  example,  to  generate  a  best 
flight  path,  starting  from  navigation 
data,  fuel  consumption  data,  mission  data 
base,  threat  localization  /  classification 
data,  obstacles  recognition  data,  etc... It 
is  possible  to  think  about  an  extended  use 
of  advanced  processing  techniques,  but  the 
pilot  will  have  to  preserve  the 
possibility  to  effectively  control  the 
system. 

Resources  required  to  run  this  kind  of 
high  level  data  fusion  are  based  on  data 
processing  system  elements. 

Fusion  of  raw  data:  digitized  raw  data 
entering  the  system  core  from  the  sensors' 
front  end  interfaces  can  be  fused  by  means 
of  signal  /  image  processing  algorithms, 
in  order  to  exploit  the  characteristics  of 


the  different  sensors,  and  enhance  the 
overall  quality  of  the  result.  Image 
fusion  is  a  very  promising  application  of 
this  concept.  For  example,  fluxes  of 
signals  carrying  unprocessed  images 
derived  from  EO  and  Radar  sensors  can  be 
combined  advantageously,  providing 
performance  enhancements.  Additional 
candidates  sources  are  stored  digitized 
maps.  It  has  also  been  demonstrated  that 
fusion  algorithms  can  be  run  with  benefit 
over  images  produced  by  two  (or  more) 
different  IR  sensors. 

Resources  required  to  run  this  kind  of  low 
level  data  fusion  are  both  signal  and  data 
processing  system  elements. 

Overall  requirements  for  the  mission  / 
system  control  processing  function  are 
estimated  as  follows: 

Data  Processing:  2000  MIPS 

Signal  Processing:  2-4  GFLOPS  (rough 

estimate) 

Memory :  4  Gbyte  (mostly  needed  for  map 
generation) . 

5.3  Crew  Interface  Control  Requirements 

The  need  has  been  envisaged  to  interface  a 
set  of  elements,  among  which  the  most 
demanding  and  dimensioning  from  the  point 
of  view  of  a  preliminary  architecture 
definition  are  1  Head-Up  Display,  1  Helmet 
Mounted  Display  and  6  Head  Down  Liquid 
Crystal  Multifunction  Displays.  This 
statement  results  directly  from  the 
adoption  of  the  Air  to  Ground  mission  as 
the  driving  one,  with  pilot  and  co-pilot. 
New  displays  will  be  inherently  digital  by 
nature,  and  there  are  significative 
advantages  to  be  gained  in  realizing  them 
as  "dumb"  displays,  with  no  incorporated 
graphic  processing  capability.  These 
advantages  range  from  size  and  power 
dissipation  of  the  display  themselves,  to 
the  centralized  generation  of  video 
signals  in  the  digital  core,  having 
beneficial  effects  on  control  and 
flexibility  of  the  system.  Digital  raw 
pixel-level  video  signals  will  therefore 
be  distributed  from  the  system  core  to  the 
display  system,  with  bandwidths  of  the 
single  channel  ranging  from  600  Mbit/s  up 
to  1.7  Gbit/s.  Proper  image  manipulation 
resources  will  have  to  be  integrated  in 
the  digital  core. 

5.4  Networking  Requirements 

Networking  is  certainly  a  crucial  topic 
for  future  integrated  avionics.  Even 
looking  solely  at  the  necessary  available 
bandwidth,  it  is  certainly  true  that  it 
grows  proportionally  with  the  available 
processing  power,  and  this  grows  of  orders 
of  magnitude  with  each  new  processor 
generation.  Moreover,  the  nature  of 
integrated  avionics  contributes  to  magnify 
the  criticality  of  networking  with  respect 
to  the  federated  approach.  Two  main 
different  kinds  of  data  transmissions  are 
present  in  the  system: 

•  Long  duration  high  data  rate, 
essentially  streaming  data  of  very  high 
data  rates  from  /  to  sensors  and  videos 

•  Short  duration  lower  bandwidth,  discrete 
packetized  transmissions  of  control  and 
status  data 
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but  there  is  a  fundamental  difference  in 
the  way  current  avionic  systems  and 
integrated  avionics  deal  with  these  kinds 
of  traffic. 

Federated  avionics  (modern  in-service 
avionics)  is  concerned  essentially  with 
low  data  rate  digital  traffic,  being  the 
system-wide  circulation  of  high  data  rate 
traffic  avoided  by  locally  performed 
computing  (e.g. :  in  sensors'  line 
replaceable  units)  or  by  transmission  of 
analog  signals  on  dedicated  connections. 

Integrated  avionics  must  on  the  contrary 
deal  with  digitized  data  traffic  of  both 
kinds  above  mentioned.  It  is  in  fact 
sufficient  to  consider  that  the  request 
for  high  integration  among  homogeneous 
functions,  and  wide  data  fusion,  calls  for 
networks  that  connect  the  multitude  of 
aircrafts  sensors  directly  with  signal  and 
data  processing  elements  integrated  in  the 
digital  core,  routing  digital  traffic, 
typically  characterized  by  high  band  and 
long  duration,  with  very  stringent  real 
time  requirements,  due  to  the  very  limited 
latencies  necessary  to  sustain  tight  close 
loop  sensors  controls.  Of  course,  bursty 
data  traffic  is  present  too,  and  will  havb 
to  be  circulated  as  well  in  the  system. 

It  can  be  underlined  how  it  is  usually 
more  effective  to  approach  with  two 
different  communication  philosophies  the 
transmission  of  the  two  kinds  of  traffic. 
It  is  well  known,  from  modern 
communication  criteria,  that  circuit¬ 
switching  techniques  are  in  general  well 
suited  for  long  duration  transmissions, 
while  packet-switching  techniques  are  well 
adaptable  to  bursty  traffic. 

After  these  preliminary  considerations, 
let  us  list  more  systematically  the  most 
important  requirements  applicable  to  the 
interconnection  subsystem  for  integrated 
modular  avionics. 

•  Use  of  a  common  interconnect  network, 
addressing  both  backplane  and  system 
level,  and  with  no  logical  difference 
between  cabinet  internal  and  cabinet 
external  connections.  This  will  allow 
effective  control  of  latencies,  as  no 
bridging  device  will  be  required,  and 
will  increase  standardization. 

•  Routing  of  both  long  duration 
(streaming)  and  short  duration  (bursty) 
data  transfers. 

•  Capability  to  be  configured  within 
specified  limits  of  growth. 

•  Support  of  fault  tolerant  operation 

•  Support  connection  of  up  to  256  physical 
entities . 

•  Assure  very  limited  maximum  transfer 
latencies,  specified  to  be  more 
stringent  for  control  than  for  data 
traffic . 

•  Assure  very  limited  maximum  linking  / 
unlinking  times. 

•  Support  data  transfer  rates  of  at  least 
2  Gbit/s.  This  requirement  descends 
directly  from  previous  considerations 
about  raw  digitized  data  produced  by 
sensors  realized  according  to  the  new 
sensor  concept,  and  from  the  necessity 
to  route  high  band  digitized  images  to 
the  crew  interfaces. 

•  Support  control  /  status  information 
transfer  rate  of  200  Mbit/s. 


•  Fiber  optic  is  required  as  physical 
transmission  media. 

Many  other  requirements  have  been  stated 
concerning  the  communication  subsystem, 
the  specification  of  which  is  not  relevant 
for  the  scope  of  this  paper. 

5.5  Fault  Tolerance  Requirement 

One  of  the  major  promises  of  modular 
architectures  is  a  significative 
improvement  of  the  overall  system  fault 
tolerance,  realized  by  means  of  extended 
dynamic  reconfiguration  capabilities. 

Among  the  specified  operational 
requirements,  the  following  have  been 
found  applicable  to  this  system  aspect: 

•  Safety  Critical  Functions  shall 
contribute  to  the  mean  rate  of  major 
accident  with  a  probability  not 
exceeding  10exp(-6)  per  flight  hour. 

•  Survival  Critical  Functions,  necessary 
for  the  aircraft  to  survive  in  a  high 
threat  environment,  shall  fail  with  a 
probability  not  exceeding  10exp(-5)  per 
flight  hour 

•  The  mission  shall  be  successfully 
completed  with  a  probability  not  less 
than  0.95. 

•  The  system  must  be  designed  to  degrade 
gracefully 

Moreover,  a  general  design  target  of 
sufficient  system  availability  after  150 
hours  without  maintenance  has  been 
indicated  as  desirable. 

In  general,  it  must  be  observed  that 
avionics  is  only  a  part  of  the  total 
weapon  system,  and  the  responsibility  of 
occurrence  of  any  kind  of  fault  is  to  be 
apportioned  among  systems  hosted  by  the 
aircraft,  finally  individuating  the 
"responsibility"  of  avionics.  Not  only, 
but,  being  here  interested  in  the  digital 
core  of  the  integrated  system,  we  should 
distinguish  it  from  the  rest  of  the 
avionic  system,  and  we  will  find  from 
available  literature  data  that  the  core  is 
responsible  for  about  20%  of  the  total 
avionic  system  failures.  In  view  of  the 
above,  it  can  be  observed  that  modular 
avionics  offers  a  chance  to  improve  the 
reliability  of  a  system,  but  there  is  not 
much  sense  in  concentrating  efforts  on  the 
core  without  improving  in  parallel  the 
analog  sensor  area. 

A  rigorous  approach  to  core  reliability 
would  require  to  provide  for  each  function 
a  configuration  of  elements  assuring  both: 

a.  The  reliability  level  required, 
distinctly,  for  flight,  survival,  mission 
critical  functions. 

b.  The  availability  level  required  (150 
hours  without  maintenance  resulting  in  a 
proper  availability  probability. 

In  order  to  apply  the  above  procedure, 
reliability  figures  are  needed  for  all  the 
physical  components  of  the  system  core. 
Even  if  these  physical  elements  will  be 
identified  later  in  this  paper,  it  is 
worth  to  observe  already  now  that, 
defining  the  modular  core  elements  as  per 
para.  6  of  this  paper,  we  should  make 
hypothesis  not  only  on  the  digital 
processing  modules  reliability  figures, 
but  also  on  power  supply  and  network 


6-6 


components.  In  particular  in  the  case  of 
network,  components,  failure  modes  and 
reliability  figures  are  not  easy  to  be 
figured  out,  presently,  without  stepping 
into  arbitrariness. 

It  has  therefore  been  decided  to  discard 
the  rigorous  approach  (which  should  be 
considered,  nevertheless,  an  interesting 
exercise  to  be  made,  in  the  expectation  of 
specific  reliability  figures) ,  and  adopt  a 
second  approach,  based  on  the  general 
operational  requirement  calling  for 
graceful  degradation.  This  has  been 
interpreted  with  a  requirement,  based  on 
evaluations  about  the  evolution  of  the 
present  systems  capability  to  tolerate 
faults,  synthesized  here  as  follows: 


Event 

n°  of 
faults 

Functional  Status 

1 

2 

full  functionality 

2 

2  +  1 

minor  degradation 

3 

2  +  1+1 

heavy  degradation 

4 

2+1+1+1 

function  loss 

Event  1:  failure  of  2  components,  which 
may  be  of  the  same  type. 

Event  2:  failure  of  3  components,  of  2  or 
3  different  types 

Event  3:  failure  of  4  components,  of  2  or 
more  different  types. 

"Component"  is  to  be  intended  as  element 
of  the  system  core. 

It  has  been  considered  that  this 
requirement  (to  be  regarded  as  minimum, 
further  improvements  being  desirable) 
would  have  promoted  a  useful  effort  in 
organizing  the  system  in  such  a  way  to 
provide  a  good  reliability  level,  by  means 
of  the  identification  of  reconfiguration 
paths  and  criteria. 

It  must  be  pointed  out  that  this 
requirement  is  not  considered  applicable 
for  flight  critical  functions.  These  have 
been  in  fact  encapsulated,  allowing 
interfaces  with  the  system  core  implying 
exchange  of  information  not  such  to  raise 
safety  critical  issues  in  the  core. 

This  approach  has  been  chosen  with  the 
following  motivations: 

•  Promote  the  possibility  of  new 
technologies  insertion  in  the  core. 

•  Lower  testability  problems  for  safety 
critical  functions,  facilitating  the 
system  certification. 

•  Avoid  the  introduction  of  dedicated 
safety  critical  modules  in  the  core, 
improving  standardization. 

The  above  has  been  interpreted  as  a 
recommendation,  and  has  been  taken  in 
account  during  the  definition  of  the 
architecture  proposal,  but  there  is  the 
awareness  that  things  may  evolve 
differently . 

6.  OVERVIEW  OF  TECHNOLOGICAL  SOLUTIONS 
ESSENTIAL  FOR  SYSTEM  ARCHITECTURE 
DEFINITION 

The  work  package  dedicated  to  Technology 
Studies  has  absorbed  more  resources  than 
any  other  section  of  the  RTP4.1  programme. 
Scope  of  this  paragraph  is  to  give  a  short 
account  of  those  technology  solutions 
which  have  been  more  important  in  defining 


the  proposed  avionic  system  architecture. 
Although  the  architectural  study  has  not 
addressed  packaging  (this  topic  has  been 
thoroughly  analyzed  by  technology  studies 
of  RTP4.1),  the  physical  realization  of 
the  system  core  can  be  synthesized  as 
follows : 

•  One  or  more  Racks,  each  hosting: 

•  Backplane 

•  Cooling  facilities 

•  Power  Distribution  facilities 

•  Line  Replaceable  Modules  (LRMs) , 
fitting  in  the  backplane  and  inside 
the  rack 

•  A  Communication  System,  which  will 
provide  data  distribution  among  the 
digital  elements  within  the  core,  and 
an  interface  toward  the  Sensor  Areas, 
the  Crew  Interface  Area  and  other 
systems  such  as  Vehicle  Control. 

For  our  scope  it  is  necessary  to  report 
some  essential  technological  results 
concerning : 

•  Modules  families 

•  Networking  solutions 

6.1  Physical  Modules  Families  - 

Performances  and  Characteristics 

In  order  to  implement  by  means  of  modular 
units  the  system  elements  pertaining  to 
the  digital  core,  reported  in  para.  4,  a 
general  standardization  criteria  has  been 
taken  in  account,  requiring  the 
minimization  of  Che  different  types  of 
modules  to  be  realized. 

Detailed  technological  studies  have  been 
carried  out,  including  review  of  currently 
available  technologies,  functional 
partitioning  in  solid-state  devices, 
packaging  solutions,  multiprocessing 
issues,  modules  functional  and  physical 
interfaces,  etc.  The  resulting  physical 
modules,  and  major  characteristics,  are 
briefly  summarized  in  the  following, 
focusing  only  on  those  apects  strictly 
relevant  for  architecture  definition. 

•  Data  Processing  Module.  Featuring  a 
processing  capability,  indicated  in 
suitable  benchmarks,  that  results 
compatible  with  a  projected  performance 
of  about  2000  MIPS.  This  is  recognized 
as  a  poor  indicator  of  processing 
performance,  but  is  comparable  with  the 
above  expressed  processing  requirements. 
Interfaces:  2  In  +  2  Out  Data  and 
Control  ports.  Memory:  preliminary 
module  design  based  on  overall  64  Mbytes 
per  module,  with  grow  capability  by  chip 
replacement  from  100%  to  300  %. 

•  Signal  /  Image  Processing  Modules .  The 
need  for  two  kind  of  signal  processing 
modules  is  envisaged: 

.  General  Purpose  Signal  Processing 
Modules ,  performing  data  dependent 
algorithms  and  complex  /  real  matrix 
operations.  Projected  processing 
performance  of  about  1000  MFLOPS . 

.  Special  Signal  Processing  Modules.  A 
dedicated  and  a  general  approach  have 
been  individuated  as  possible.  As  for 
the  system  design,  the  general  one  has 
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been  taken  as  reference,  having  the 
lower  Impact  on  the  system  size. 
According  to  this  approach,  an  Array 
Processing  Module  is  needed,  performing 
frequency  analysis,  filtering  and 
correlation  algorithms.  Projected 
processing  capability:  about  4  GFLOPS. 

Interfaces:  2  In  +  2  Out  data  ports  per 
module  at  system  level.  Other  ports  are 
available  to  realize  a  dedicated  signal 
processing  architecture.  2  In  +  2  Out 
control  ports. 

Memory:  estimated  between  64  and  128 
Mbytes  (overall  contained  on  board) . 

•  Graphic  Processing  Module.  Capable  to 
realize  image  manipulations  like 
translations,  rotations,  zooming, 
dimming,  compression  /  decompressions, 
etc.,  images  mixing,  production  of 
digitized  images  with  resolution  up  to 
2048  X  2048  pixels,  50  Hz  refresh  rate, 
bandwidth  up  to  1.7  Gbit/s.  Interfaces: 

2  In  +  2  Out  Data  and  Control  ports. 

•  Crypto  Processing  Module.  Dedicated  to 
encrypt  /  decrypt  secure  communications 
transmitted  /  received  by  the  aircraft. 

It  will  be  specific  to  the  type  of 
encryption  used,  in  order  to  meet 
stringent  certification  requirements. 
Interfaces:  2  In  2  Out  Data  and 
Control  ports. 

•  Mass  memory  Module.  Dedicated  to  store 
huge  amount  of  data,  e.g.  maintenance 
data  for  off  line  evaluation  or  digital 
maps.  Projected  storage  capacity  of 
about  2  Gbytes,  achievable  in  the  useful 
time  frame  by  means  of  electronic 
components,  featuring  more  robustness 
and  faster  access  times  than  magnetic  or 
optical  devices. 

•  Power  Conditioning  Modules .  The  power 
supply  subsystem  has  been  analyzed  in 
detail  by  technology  studies.  Here, 
their  presence  will  be  taken  in  account 
from  a  purely  functional  point  of  view. 

•  Network  Modules.  Treated  in  the  next 
paragraphs . 

6.2  Networking  Solutions 

It  is  quite  clear  that  the  basic 
requirement  to  build  the  avionic  system 
around  a  unifying  homogeneous  network  does 
not  cope  easily  with  other  requirements, 
in  particular  in  view  of  the  existence  of 
two  basically  different  classes  of 
information  transfers  across  the  system: 
high  rate  streaming  data  transfers  (e.g. 
digitized  signals  from  sensors  areas  and 
to  the  crew  interface)  and  low  rate  bursty 
data  transfers  (e.g.:  control 
information) .  A  single  unified  network  is 
still  to  be  pursued,  but  not  all  of  the 
required  technology  is  today  available. 

The  proposed  solution  realizes  a 
conciliation  of  opposite  demands, 
presenting  a  Matrix  Switch  Network  (MSN) 
concept  (see  Ref.  3  for  a  complete 
treatment  of  the  subject)  that  combines: 

•  A  primary  (circuit  switch)  network, 
providing  high  band  point  to  point 
optical  transmission  paths,  configurable 
by -means  of  switching  elements.  Due  to 


the  circuit  switch  technique,  this 
network  is  well  suited  to  high  rates 
data  transfers  requiring  the  whole 
bandwidth  of  the  physical  links  to  be 
available.  It  will  be  named  in  the 
following  MSN  Data  Transmission  Network. 
•  A  secondary  network,  suitable  Co  carry 
control  /  status  information  and  lower 
rate  data  transfers,  named  MSN  Control 
and  Message  Network. 

This  networking  scheme  is  briefly 
represented  in  Fig.  3.  As  it  can  be  seen, 
the  central  element  of  the  MSN  Data 
Transmission  Network  is  the  Link  Control 
Element  (LCE) ,  constituted  by  the  Switch 
Matrix  and  the  Matrix  Controller, 

The  Switch  Matrix  is  to  be  developed  in 
the  long  term  as  a  large  purely  optical 
array,  while  a  mid-term  solution  could  be 
to  have  an  electronic  switching  element 
and  optical  /  electro  /  optical 
conversions.  It  should  be  noted  how  the 
first  solution  will  drive  the  choice  of 
the  physical  media,  requiring  use  of 
monomode  optical  fibers 

In  accordance  with  the  modular  approach, 
it  seems  interesting  to  realize  the 
switching  elements  as  modules  (and  this 
explains  the  "Network  Modules"  recalled  in 
para .  6.1). 

A  switch  matrix  size  of  32  Input  x  32 
Output  ports  is  assumed  for  the 
LCE  implementation,  on  the  basis  that  this 
is  expected  to  be  the  maximum  size  to  be 
produced  in  the  relevant  time  scales.  A 
limited  number  of  output  ports  are 
configurable  for  inter-LCE  connections. 
Optical  backplanes  will  be  used  to  carry 
the  circuit  switched  channels  to  any  LRM 
requiring  high  data  rate  connections. 

Primary  function  of  the  Control  and 
Message  Network  is  to  carry  all  the 
signaling  and  notification  information 
required  to  establish  the  MSN  dedicated 
connections.  The  request  for  a  physical 
connection  is  issued  by  a  network 
subscriber  and  notified  to  the  Matrix 
Controller,  which,  depending  also  on  its 
current  status,  reconfigures  the  Matrix. 

As  for  the  realization  of  the  Control  and 
Message  Network,  a  range  of  possible 
alternatives  has  been  individuated,  all 
implementing  packet  switching  techniques. 
Asynchronous  Transfer  Mode  (ATM)  being  the 
most  promising,  followed  by  Scalable 
Coherent  Interface  /  Real  Time  (SCI/RT) 
and  Fiber  Distributed  Data  Interface 
(FDDI) ,  this  last  suffering  for  a 
disadvantage  in  granting  the  low  latencies 
required,  due  to  its  ring  topology.  As  for 
ATM,  it  results  preferable  not  only  due  to 
a  weighted  requirements  analysis,  but  also 
for  its  large  and  growing  commercial 
diffusion,  boosting  performances  and 
lowering  costs. 

ATM  networks  typically  consist  of  nodes 
connected  in  a  mesh  type  topology.  Each 
node  controls  its  outgoing  communication 
lines,  and  no  common  access  is  provided. 

An  ATM  network  requires  its  independent 
switch  matrices,  and  this  means  that  an 
ATM  controlled  MSN  will  use  two  different 
types  of  switch  matrices. 

Although  a  preference  has  been  given  to 
ATM,  a  final  choice  for  the  Message  and 
Control  Network  has  not  been  done. 

Finally,  it  should  be  noted  how,  as  long 
term  unifying  networking  solution,  ATM 
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seems  to  have  good  chances,  due  to  highly 
improved  performances  (e.g.  2.5  Gbit/s 
data  rate)  projected  for  the  future. 

7.  SYSTEM  ARCHITECTURE  PROPOSAL 

The  resulting  architecture  proposal  is 
shown  in  Fig.  4.  A  subdivision  in  a  number 
of  areas  can  be  noticed,  arranged 
horizontally  in  the  figure,  each 
integrating  an  analog  block  front-end 
(exception  made  for  area  1) ,  switching 
network  facilities,  and  an  integrated 
digital  processing  block  (IDPB),  hosting 
the  modules.  It  should  be  underlined  that 
one  IDPB  is  not  to  be  regarded  as  one 
rack,  being  the  architecture,  in  this 
sense,  at  functional  (not  physical)  level. 
The  following  considerations  will  show 
rationales  and  features  of  this 
architectural  model. 

The  estimates  of  computing  and  memory 
requirements  referred  to  the  sensor 
control  processing  and  mission  /  system 
control  processing,  compared  with  the 
technical  characteristics  of  the  modules 
and  corrected  with  general  multiprocessing 
efficiency  criteria,  yield  the  number  of 
modules,  for  each  type,  required  to  carry 
out  all  the  necessary  functions,  in  the 
absence  of  failures.  Confronting  the  high 
overall  number  of  modules,  each  equipped 
with  2  In  and  2  Out  MSN  ports,  with  the 
availability  of  LCEs  with  32In  x  320ut 
ports,  it  results  hardly  feasible  to 
realize  a  system  allowing  a  connection 
with  the  required  characteristics  to  be 
established  between  any  couple  of  elements 
of  the  system.  Schemes  could  be  elaborated 
to  match  this  full  connectivity,  cascading 
a  number  of  LCEs,  but  they  would  impact  on 
the  system  complexity,  posing  control  and 
latency  problems.  An  attempt  to  realize  an 
unlimited  reconfiguration  has  therefore  be 
abandoned,  in  favour  of  an  architecture 
scheme  subdivided  in  reconfiguration 
areas,  each  area  being  served  by  LCEs  in 
such  a  way  to  allow  any  interconnection 
scheme  to  be  established  within  the  area, 
and  to  be  reconfigured  when  necessary,  not 
only  among  the  modules  of  the  IDPB,  but 
also  between  the  IDPB  and  the  sensor 
front-end.  The  reconfiguration  among 
elements  pertaining  to  different  areas 
will  be  limited,  depending  on  the 
available  interconnections  among  LCEs 
belonging  to  different  areas. 
Reconfiguration  areas  are  chosen  on  the 
base  of  close  functional  bounds,  implying 
necessity  for  extensive  data  transfers 
among  elements,  and  on  the  base  of  number 
of  elements  required  for  functional  area. 
Primarily,  the  following  reconfiguration 
areas  have  been  individuated: 

•  Mission  /  System  Management  and  Crew 
Interface 

•  Communication  /  Navigation  / 
Identification  (CNI) 

•  Multimode  radar 

•  Integrated  Defensive  Aids 

•  Integrated  Electro  /  Optical 

The  sensor  blocks  of  CNI,  Multimode  Radar 
and  Integrated  Defensive  Aids  have  been 
reported  as  separated  in  the  figure,  to 
point  out  the  different  specific  functions 


carried  out  in  the  RF  domain,  but  it  is 
well  understood  that  integration  (and 
modularity)  is  to  be  pursued  at  analog 
sensor  level  too,  primarily  RF,  and  not  be 
limited  to  the  digital  core.  Similarly, 
the  digital  processing  of  the  RF 
applications  tends  to  be  strictly 
Integrated,  as  explained  in  the  following. 

It  is  to  be  noted  that  the  interface 
toward  the  sensor  front-end  can  be  quite 
demanding  in  terms  of  number  of  required 
links,  as  underlined  by  some  technology 
studies . 

The  fault  tolerance  requirement  must  be 
met .  To  this  aim,  each  area  must  be 
equipped,  in  principle,  with  2  redundant 
modules  for  each  of  the  needed  types  of 
LRMs .  As  a  result,  the  overall  system  core 
will  be  equipped  approximately  with  the 
types  and  number  of  modules  reported  in 
the  first  row  of  Tab. 3. 

The  resulting  overall  number  of  modules 
for  each  area,  together  with  connection 
requirements  toward  sensors  and  actuators 
front  ends,  is  such  to  engage  more  than 
the  interconnection  capabilities  of  1  LCE 
for  every  area,  should  2  Input  and  2 
Output  ports  per  module  be  connected  to 
the  LCE.  On  the  other  hand,  this  LCE  must 
be  duplicated  to  tolerate  its  fault.  In 
realizing  connections  between  modules  and 
the  2  LCEs,  it  will  be  possible  to  connect 
each  module  to  both  LCEs,  using  both  pairs 
of  I/O  ports  available  on  the  modules,  one 
per  LCE.  It  can  be  seen  that,  with  this 
configuration,  a  number  of  LCEs  ports  are 
not  utilized,  their  number  depending  also 
on  the  specific  implementation  of  the 
sensor  blocks  interfaces.  A  way  of  using 
these  ports  is  to  configure  them  as  inter 
LCE  connections  among  different  areas, 
providing  a  certain  level  of 
reconfiguration  among  areas.  In 
particular,  this  will  be  done  among  the 
areas  pertaining  to  the  RF  partition, 
integrating  them  as  far  as  possible . 
Considering  also  that  not  all  the  possible 
interconnection  schemes  are  necessary,  as 
information  flows  logically  across  the 
system,  and  not  in  any  possible  direction, 
a  sufficient  linkage  level  can  then  be 
achieved  among  IDPBs  2,3,4,  such  to 
resemble  the  existence  of  a  unique  RF 
digital  reconfiguration  area.  In  this 
case,  less  redundant  elements  will  be 
necessary,  as  they  will  not  be  replicated 
for  IDPB  2,3,4.  The  resulting  approximate 
overall  number  of  modules  for  this 
solution  (3  primary  reconfiguration  areas: 
Mission/System  Management  and  Crew 
Interface,  Integrated  RF,  Integrated  EO) 
is  reported  in  the  second  row  of  Tab.  3 
(for  correctness,  it  should  be  pointed  out 
that  this  quantitative  evaluation  has  been 
made  outside  the  RTP4 . 1  study). 

A  couple  of  LCEs  is  not  yet  enough  to 
tolerate  a  double  catastrophic  fault  at 
LCEs  level.  The  following  solutions  can  be 
identified: 

•  Addition  of  a  third  LCE  for  each  area 

•  Use  of  not  engaged  LCEs  ports  of,  e.g., 
area  2,  to  provide  an  alternative  route 
among  the  sensor  block  and  the  modules 
of ,  e.g.,  area  1 

•  Addition  of  a  spare  reconfiguration 
area,  equipped  with  limited  resources 
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(single  redounded) ,  to  be  substituted  to 
any  of  the  primary  areas  in  case  of 
total  fault  of  any  of  these  areas  due  to 
double  LCEs  failure 

The  third  one  is  the  solution  proposed. 
Although  it  has  the  disadvantage  of 
requiring  its  own  set  of  modules,  it 
utilizes  in  principle  a  lower  number  of 
LCEs  than  the  first,  and  should  be  more 
easily  controllable.  The  second  solution 
would  be  no  cost,  but  conditioned  by  the 
effective  sufficient  availability  of  spare 
LCEs  ports.  It  should  be  underlined  that 
the  effective  necessity  to  cope  with  total 
fails  of  LCEs  will  have  to  be  verified 
when  specific  data  about  failure  modes  and 
rates  of  these  components  will  be 
available.  Considering  also  that  the 
second  solution  may  reveal  possible,  the 
additional  spare  area  should  be 
considered,  at  the  moment,  as  optional , 
not  part  of  the  basic  architecture . 

The  control  and  message  network  has  been 
outlined  quite  generally  in  the  figure,  as 
no  final  choice  has  been  done  about  its 
implementation.  It  will  have  to  be 
properly  redounded. 

The  outlined  architecture  satisfies  and 
exceeds,  in  principle,  the  fault  tolerance 
requirement.  In  fact,  the  fail  of  any  2 
identical  elements  of  the  system  (event  1 
of  the  fault  tolerance  requirement)  does 
not  degrade  performances,  as  a  proper 
reconfiguration  within  the  same  area  will 
allow  the  exploitment  of  substitutive 
resources.  Event  2  (fail  of  a  third  but 
different  element)  results  still  in  no 
performance  loss.  The  most  stringent  case 
is  in  fact  the  one  for  which  one  area  is 
completely  failed  due  to  the  failure  of 
two  LCEs.  In  this  case  the  spare  area 
becomes  active,  equipped  with  a  number  of 
modules  integrating  a  single  redundant 
element  for  each  of  the  needed  types  of 
modules,  which  allows  the  overcoming  of 
any  single  fault. 

Further  fails  of  the  same  type  of 
components  (worst  case  of  event  3  of 
requirement)  degrade  performances,  but 
only  when  occurring  in  the  same 
reconfiguration  area.  In  general,  it 
should  be  noted  that,  once  the 
availability  of  spares  is  over, 
reconfiguration  schemes  can  take  place 
among  active  components  also, 
redistributing  tasks  among  them,  obtaining 
a  graceful  degradation  of  performances. 

The  architecture  topology  allows  the 
realization  of  data  fusion  strategies . 

A  specific  reconfiguration  area  (Mission 
Management)  has  been  equipped  with 
resources  dedicated  for  data  fusion,  and 
it  is  possible  to  supply  to  this  areas 
pre-processed  information,  or  raw  data 
outcoming  from  sensor  front-ends, 
depending  on  which  specific  strategy  of 
data  fusion  is  requested  on  the  specific 
phase  of  the  mission.  This  is  done  by 
means  of  the  inter-LCEs  connections 
between  the  Mission  Management  area  and 
the  various  sensor  areas  interested  by 
data  fusion  algorithms  (see  para.  5.2  for 
requirements) . 

The  implementation  of  specialized  data 
fusion  algorithms  in  the  area  dedicated 
also  to  crew  interface  seems  advantageous, 
as  the  results  of  image/data  fusion 
require  typically  an  effective  interface 


toward  displays,  provided  in  this  area  by 
means  of  an  extensive  use  of  graphic 
processing  resources,  connected  to 
displays  through  LCEs.  Nevertheless, 
displays  can  be  driven  also  by  any  other 
area,  improving  the  reliability  of  the 
crew  interface  function. 

8.  CONCLUSION 

The  paper  has  briefly  outlined  the  logical 
process  which,  within  RTP4.1,  has  been 
adopted  to  define  a  suitable  modular 
integrated  system  architecture.  The  most 
relevant  results  and  rationales  have  been 
reported.  Important  features  of  the 
architectural  model  have  been  discussed, 
as  the  capability  to  tolerate  faults  and 
performing  data  fusion  at  various  levels. 

It  is  worth  noting  how  a  topic  as  system 
architecture  definition  encompasses 
software  architecture  as  well.  Strong 
efforts  have  been  carried  out  in  this 
direction  by  RTP4.1,  but  the  subject  was 
outside  the  scope  of  this  paper. 

Concluding,  the  architectural  studies 
herein  described  cannot  claim  any 
conclusive  value.  Requirements  and 
technological  variables  are  still  too  many 
to  allow  a  definitive  result  to  be 
reached,  and,  at  the  same  time, 
experimental  activities  on  laboratory 
prototypes  will  have  to  be  carried  out. 
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Functional  Macro  Areas 

Subfunctions 

Necessary  System  Elements 

Vehicle/Stores  Control 

.  Inlet  Control 
.  Propulsion  Control 
.  Electrical  Power  Control 
.  Armament  Management  Control 
.  Flight  Control 

Data/Control  Processing 

Mission/System  Control 

.  Mission  Initialization 
.  Navigation  /  Flight  Path 

Generation 

.  Data  /  Image  Fusion 
.  Image  Analysis  /  Classification 
.  Integrated  Diagnostics 
.  System  Reconfiguration 

Signal/Data/Control  Processing 

Sensor  Control 

.  Sensor  Configuration 
.  Communication  Management 
.  Target  Detection 

Signal/Data/Control  Processing 

Crew  Interface  Control 

.  Image  /  Map  Generation 
.  Crew  Selection  Acquisition 

Data/Control  Processing 

Table  1  -  Functional  Partitioning 


Sensor 

Data 

Processing 

(MIPS) 

Signal 

Processing 

(GFLOPS) 

Memory 

(MByte) 

Output 
Data  Rate 
(Gbit/s) 

Iteration 

Time 

(msec) 

Multimode  Radar 

500 

10.0 

100 

1.4 

1 

EO 

1000 

7.5 

40 

1.0 

40 

Integrated  Defensive  Aids 

1200 

10.0 

200 

2.0 

1-40 

CNI 

200 

3.0 

35 

3.0 

>25 

Table  2  -  Sensor  Processing  and  Interface  Requirements. 


Architectural  Solution 

Data 

Processing 

LRMs 

Generic/Specific 
Signal  Processing 
LRMs 

Crypto 

Processing 

LRMs 

Graphic 

Processing 

LRMs 

Mass 

Memory 

LRMs 

5  Reconfiguration  Areas 

17 

41  -  43 

3 

20 

4 

3  Reconfiguration  Areas 

11 

33-35 

3 

14 

4 

Table  3  -  Estimated  number  of  processing  modules 
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avionic  architectures;  integrated  modular  avionics. 

1.  ABSTRACT 

With  the  dramatic  reduction  in  defense  spending  in  NATO 
countries,  it  is  quite  clear  that  there  will  be  few  new  military 
aircraft  for  perhaps  many  years.  A  consequence  is  that  there 
will  be  widespread  use  of  current  aircraft  to  satisfy  future 
military  mission  requirements.  One  of  the  most  cost-effective 
means  for  improving  the  capability  of  a  military  aircraft  to  deal 
with  new  threats  and  mission  requirements  is  to  upgrade  the 
performance  of  the  avionics  suite.  However,  current  federated 
avionics  subsystems  are  weapon-system  unique,  have  limited  ' 
capability  and  life  and  may  not  support  new  functional 
requirements.  In  addition,  the  cost  of  performance  upgrades 
for  federated  avionic  suites  are  prohibitive,  particularly  in 
terms  of  the  budgets  available.  Integrated,  modular  avionics 
technologies  offer  substantial  potential  for  improving  the 
reliability  and  reducing  the  cost/weight/volume  per  function 
for  adding  new  functional  capability.  Integrated,  modular 
avionics  are  normally  considered  for  new  aircraft,  but  there  is 
some  evidence  that  they  may  have  potential  in  some 
circumstances  for  older  aircraft  as  well.  This  paper  examines 
several  military  aircraft  applications  and  discusses  the 
circumstances  where  the  retrofit  of  an  advanced  avionics 
architecture  may  be  preferred  to  more  conventional 
approaches.  The  major  consideration  is  cost  per  function.  The 
paper  will  show  that  the  advanced  architecture  is  a  clear 
winner  as  the  number  of  functions  is  significant  in  terms  of  the 
level  of  integration  required  with  other  subsystems.  It  is  very 
difficult  to  determine  with  even  coarse  precision  the  costs  of 
various  approaches,  but  certain  trends  are  apparent.  Not  too 
surprisingly,  the  dominant  aequisition  cost  is  not  the  avionics 
equipment,  but  the  cost  of  installing  and  integrating  the 
equipment  into  the  aircraft  together  with  the  cost  of  testing, 
documentation  and  training. 

2.  SUMMARY 

This  paper  identifies  the  need  to  upgrade  the  aging  federated 
avionic  systems  on  older  aircraft  with  new  Integrated  Modular 
Avionics  (IMA)  architectures  that  are  more  capable  of  meeting 
the  needs  of  future  missions  and  operations.  Aging  avionic 
systems  are  in  need  of  upgrading  due  to  the  increasing 
problems  of  obsolescence,  poor  reliability  and  the  difficulty  of 
modifying  old  systems  to  meet  new  requirements.  The 
benefits  of  IMA  are  reduced  cost  and  weight,  and  increased 
reliability.  IMA  will  have  most  benefit  in  saving  organization 
and  support  costs  and  future  modification  costs  whilst  saving 
weight  and  volume  for  use  by  other  systems  and  equipment. 
The  factors  which  most  affect  the  outcome  of  studies  into  the 
viability  of  upgrading  with  new  architectures  are  the  total 
number  of  aircraft  across  which  the  modification  costs  can  be 


spread,  the  number,  complexity  and  suitability  of  the  functions 
selected,  the  environmental  cooling  needed,  the  weight, 
volume  and  density  of  the  new  architecture  and  the  candidate 
aircraft’s  capacity  to  accommodate  the  new  units.  Cost-benefit 
analyses  indicate  that  IMA  can  be  cost-effective  given  the  right 
parameters.  The  Science  and  Technology  community  can 
contribute  to  the  viability  by  concentrating  effort  in  several 
areas  where  IMA  could  be  made  even  more  cost  effective.  The 
impact  of  adopting  IMA  on  the  avionic  manufacturing  base 
will  be  significant.  IMA  presents  new  challenges  and 
opportunities  for  the  brave  whilst  allowing  more  of  the 
available  money  to  be  spent  on  additional  functionality. 

3.  INTRODUCTION 

3.1.  The  United  States  Air  Force  has  completed  many  studies 
into  the  viability  of  new  avionics  architectures  with  the 
objective  of  deciding  the  way  forward  for  future  avionics 
systems.  Based  on  these  studies,  the  designers  of  the  latest 
technology  fighter  aircraft  have  chosen  integrated  modular 
architectures  for  their  avionic  systems.  More  recent  studies 
have  sought  to  identify  the  most  cost-effective  method  of 
providing  greater  functionality  and  capability  to  older  aircraft. 

3.2.  The  cost  of  maintaining  older  avionics  systems  continues 
to  increase  and  in  some  cases  they  are  becoming  unsupportable 
due  to  the  obsolescence  of  parts  and  poor  reliability.  The  basic 
law  of  supply-and-demand  has  driven  the  cost  of  some  items  to 
exorbitant  heights.  In  addition,  the  continued  pressure  to 
provide  additional  functionality  and  capability  from  older 
systems  has  stretched  federated  system  technology  to  its  limits. 
The  cost  of  upgrading  old  systems  or  providing  them  with 
additional  functionality  will  therefore  remain  very  high. 
However,  at  some  point  this  objective  would  be  better  met  by 
changing  to  new  architectures  which  would  meet  the 
challenges  and  provide  additional  benefits  such  as  the  capacity 
for  growth  needed  to  satisfy  the  operational  needs  of  the 
foreseeable  future.  This  paper  seeks  to  identify  the  factors  that 
will  influence  the  point  at  which  it  would  be  viable  to  use 
advanced  avionics  architectures  to  upgrade  federated 
architecture-based  systems  on  aging  aircraft.  This  paper 
covers  the  background  to  this  question,  identifies  the  driving 
factors  behind  the  need  to  upgrade  aging  systems,  explains 
those  factors  which  most  affect  the  viability  of  upgrading 
aging  systems  with  advanced  architectures,  presents  some  of 
the  science  and  technology  which  could  affect  future  decisions 
and,  finally,  considers  some  of  the  impacts  such  action  could 
have  on  the  avionic  manufacturing  base. 

3.3.  For  the  purpose  of  this  paper  the  following  terms  are 
defined: 

a.  Federated  Systems.  Federated  systems  have  their  own 
chain  of  apertures,  sensors,  transducers,  transmitters, 
receivers,  pre-processors,  signal  processors  and. 
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sometimes,  their  own  displays.  Some  integration  might  be 
provided  by  databases  such  as  STANAG  3838  (MIL  STD 
1553B).  Each  federated  system  contains  resources  that  are 
duplicated  in  other  systems  and  rarely  are  any  used  to  full 
capacity  all  the  time.  An  illustration  of  a  federated  system 
is  at  Figure  1. 

b.  Integrated  Modular  Avionics  (IMA).  Integrated 
avionics  architectures  integrate  the  functions  of  the 
systems  it  covers  thereby  sharing  the  available  resources 
and  reducing  duplication.  Thus,  in  an  IMA  system,  there 
would  be  fewer  items  such  as  power  supplies,  boxes, 
chassis  and  cabling.  Resources,  such  as  processors,  are 
centralized  for  managed  utilization  by  a  control  layer  of 
core  processing.  In  most  examples  the  modules  are  located 
in  one  or  more  racks.  IMA  can  comprise  digital  data 
processing,  signal  processing  or  both.  Figure  2  shows  an 
example  of  an  IMA  system. 

c.  Distributed  Processing  Architecture.  Distributed 
architectures  allows  sub-systems  to  process  their  own  data 
with  the  main  integration  computing  left  to  a  central 
computer.  However,  unlike  IMA,  distributed  processing 
architectures  allows  sub-system  and  main  computing 
elements  to  be  undertaken  by  any  one  of  a  number  of  the 
sub-system  processing  elements.  Distributed  architectures 
are  therefore  thought  to  be  more  reliable  and  resilient  to 
battle  damage. 

4.  BACKGROUND 

4. 1 .  Federated  systems  have  proved  to  be  effective  pillars  of 
avionics  architectures  for  many  years.  Indeed,  Figure  3  shows 
the  number  of  Shop  Replaceable  Unit  (SRUs),  Line 
Replaceable  Units  (LRUs),  systems  and  aircraft  types  currently 
being  supported  by  the  USAF  based  on  this  technology. 
However,  with  the  demand  for  more  functionality  has  come 
new  levels  of  complexity  and  the  need  for  greater  integration. 
The  resulting  federated  systems,  integrated  by  databases  and 
hard-wired  discreet  signals,  have  become  complex  challenges 
for  designers,  support  organizations  and  maintenance 
engineers.  It  is  not  uncommon  for  sub-systems  of  varying 
complexity  and  technology  employing  different  levels  of 
hardware  and  software  sophistication  to  be  wired  together  in  a 
time-critical  manner.  These  systems  do  not  tolerate  easily 
modifications  or  change  in  any  form.  As  a  result  even  modest 
improvements  can  be  difficult  or  impossible  to  make  without 
introducing  unwanted  problems.  The  demands  made  of 
avionics  systems  are  likely  to  continue  to  grow  necessitating 
ever  more  processing  power,  bandwidth  and  capacities. 

4.2.  Researchers  and  managers  of  modem  aircraft  projects 
currently  in  design  and  in  production  foresee  great  benefit 
from  new  avionics  architectures.  It  is  believed  by  many 
scientists  and  engineers  that  these  benefits  could  be  extended 
to  aging  aircraft  by  using  architectures  identical  to  those  on  the 
latest  aircraft  thereby  reducing  the  combined  overall  cost  of 
acquiring  and  supporting  these  systems.  Further  benefits  and 
savings  could  then  accrue  from  the  standardization  and 
commonality  that  would  follow  such  a  strategy. 

4.3.  Recent  investigations  in  the  USAF  have  sought  to 
identify  the  value  of  the  proposed  benefits  of  introducing  new 
architectures  into  aging  aircraft.  This  paper  covers  the  issues 
of  fitting  advanced  avionics  architectures  to  aging  aircraft  and 
identifies  the  areas  any  such  proposal  should  consider. 


5.  THE  NEED  TO  UPGRADE 

5.1.  The  maintenance  and  support  issues  of  older  aircraft  are 
now  posing  more  urgent  questions  than  for  new  aircraft.  The 
need  to  upgrade  aging  aircraft  systems  stem  from  one  of  the 
following  factors: 

a.  Obsolescence.  Parts  become  obsolete  for  many 
reasons  resulting  in  the  need  to  find  compatible 
replacements  or  to  modify  the  system  or  part  thereof  The 
cost  of  replacing  obsolete  parts  is  well  known  to 
maintainers,  however,  one  example  typifies  the  problem. 

A  high  performance  sunlight-readable  cathode-ray  tube 
originally  cost  less  than  $200.  When  the  initial  spares  buy 
was  depleted  the  original  manufacturer  was  no  longer  in 
business.  Competitive  tendering  resulted  in  the  winning 
contractor  manufacturing  a  years  supply  at  $2,000  each. 
When  this  supply  was  depleted  only  1  contractor 
responded  to  the  invitation  to  tender  and  quoted  prices  in 
excess  of  $10,000  each. 

b.  Bad  Actors.  Poor  in-service  reliability  causes  a  higher 
than  expected  need  to  replace  and  repair  the  item  resulting 
in  higher  maintenance  costs  and  loss  of  system  availability. 
Poor  reliability  of  aging  avionics  items  has  seen  examples 
of  support  costs  rising  by  as  much  as  50%  per  year. 

c.  Performance  Upgrades.  The  need  to  undertake  more 
demanding  missions,  meet  new  challenges,  and  counter 
new  threats  has  resulted  in  the  continuous  review  of 
proposed  performance  upgrades  to  aircraft  and  their 
systems.  As  complex  systems  with  increased  data 
requirements  and  capabilities  are  introduced,  the  need  for 
architectures  beyond  traditional  federated  systems  grows 
more  necessary.  Many  systems  of  the  future  will  require 
much  greater  bandwidth  and  speed  for  their  full  potential 
to  be  realized.  Simply  adding  more  databases  is 
insufficient,  impractical  and  wasteful.  A  new  architecture, 
such  as  IMA,  is  a  necessity  to  host  such  systems. 

5.2.  It  is  difficult  to  determine  precisely  how  much  money  is 
spent  addressing  any  one  of  the  above  categories  as,  in 
practice,  modifications  tend  to  be  bundled  together  as  part  of  a 
single  program  which  addresses  several  issues  at  the  same 
time.  However,  performance  upgrades  are  continuously  under 
review  for  most  aircraft  but  are  frequently  rejected  due  to  a 
lack  of  sufficient  funds.  Bad  actors  are  more  prevalent  with 
aircraft  in  the  early  and  late  stages  of  their  service  life  and  are  a 
growing  concern  to  those  responsible  for  maintaining  aging 
aircraft.  Obsolescence  is  a  growing  problem  aggravated  by  the 
rapid  development  of  new  products  in  the  commercial  market 
leading  to  shorter  availability  lives  and  by  keeping  older 
aircraft  in  service  for  longer  than  originally  envisaged. 

5.3.  As  the  cost  of  maintaining  and  supporting  aging  systems 
continues  to  increase  there  must  come  a  time  when  two 
decisions  have  to  be  made.  The  first  decision  is  whether  to 
upgrade  the  system  or  continue  to  suffer  the  costs  and 
limitations  of  aging  systems.  The  second  decision  is  whether 
to  upgrade  the  old  federated  architecture  with  more  of  the 
same  or  to  strive  to  take  the  advantage  and  introduce  new 
architectures  that  will  give  the  aircraft  greater  capability  and 
the  maintenance  organization  greater  flexibility  to  meet  the 
challenges  of  the  future.  For  most  air  forces,  regardless  of  the 
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perceived  advantages,  any  new  solution  must  be  proved  cost- 
effective  over  the  remaining  life-cycle  of  the  weapon  system. 

5.4.  The  largest  single  cost  of  significant  avionic  upgrades  is 
often  that  for  Group  A  costs.  Group  A  costs  are  all  those  costs 
incurred  in  providing  the  installation  and  location  on  the 
aircraft  excluding  the  cost  of  the  modified  equipment  itself 
The  need  for  new  wiring,  structural  modification  and  software 
rewrites  can  obviate  all  but  the  most  essential  upgrades.  In  one 
example,  equipment  costing  less  than  $150k  per  aircraft  was  to 
be  fitted  to  10  aircraft.  The  Group  A  costs  totaled  more  than 
$5M.  Another,  non-struetural  modification,  sought  to  fit  a 
$10k  electronic  unit.  Group  A  costs  were  in  excess  of  $75k 
per  aircraft.  In  some  countries  the  virtual  monopoly  enjoyed 
by  contractors  with  sole  design  authority  rights  reduces  the 
possibility  of  competing  the  installation  and  Group  A  costs 
become  an  even  greater  obstacle. 

6.  WHEN  DOES  IMA  MAKE  SENSE? 

6.1.  The  USAF  has  undertaken  cost-benefit  analysis 
investigations  into  identifying  the  costs  associated  with 
introducing  IMA  into  aging  aircraft  and  to  determine  the  point 
where  the  new  architectures  become  viable  compared  to 
traditional  federated  architectures.  The  issues  and  general 
conclusions  are  of  value  to  all  air  forces  considering 
undertaking  similar  investigations. 

6.2.  Cost-Benefit  Analysis  (CBA).  For  most  organizations 
the  decision  process  requires  completion  of  a  comprehensive 
CBA  showing  the  cost  effectiveness  of  the  various  approaches 
being  considered.  Upgrading  a  single  federated  system  would 
almost  certainly  provide  no  cost-effective  alternative  but  to 
upgrade  it  with  a  similar  federated  system.  However,  as  shown 
in  Figure  5,  as  the  number  of  avionic  units  to  be  upgraded  and 
additional  requirements,  functionality,  capability,  and 
integration  are  added,  the  benefits  of  new  architectures 
become  more  affordable.  For  example,  when  upgrading  a 
radar  system  electronic  unit,  the  most  cost-effective  strategy 
would  normally  be  to  replace  it  with  a  new  federated  electronic 
unit.  But  when  upgrading  an  entire  communications  suite  and 
adding  new  functions  and  capabilities  to  the  requirement,  new 
architectures  become  more  viable.  Providing  basic  disparate 
systems  with  no  common  functions  or  requirements  would 
probably  not  prove  viable,  whereas,  providing  several 
computing-intensive  communications,  navigation  and 
identification  functions  would  probably  be  worthy  of  close 
analysis.  It  is  essential  that  the  CBA  compares  like  with  like. 

It  is  not  correct,  as  some  have  tried,  to  compare  modem  IMA 
upgrades  with  upgrades  based  on  old  federated  architectures. 
The  benefits  and  costs  of  new  IMA  upgrades  must  be 
compared  to  new  federated  upgrades.  Thus  the  advantages  of 
open  architectures,  standardization  and  commercialization  are 
equally  applicable  to  both  cases.  Accurate  reliability  and 
maintainability  data  must  be  intelligently  used  to  arrive  at  a 
logical  conclusion.  The  use  of  extraordinary  data  such  as  that 
from  Operation  Desert  Storm  should  be  used  with  caution  as 
such  data  is  tainted  by  environmental  and  operational 
peculiarities. 

6.3.  The  Benefits  of  IMA.  The  benefits  of  IMA  can  be 
summarized  under  three  headings:  Cost,  Weight  and  Volume, 
and  Reliability. 

6.3.1.  Cost.  The  objective  of  IMA  development  has  always 
been  to  reduce  the  future  eosts  of  avionic  architectures.  Figure 


4  shows  how  the  future  overall  cost  of  avionic  architectures 
should  be  reduced  by  the  adoption  of  IMA,  and  how 
organization  and  support  costs  should  be  reduced  by  the 
greatest  proportion.  The  overall  eost  of  the  modification  will 
vary  widely  between  different  air  forces  due  to  different  ways 
of  doing  business.  The  following  examples  are  representative 
of  the  results  from  various  studies  and  cover  the  main 
categories  of  cost. 

a.  Engineering  &  Manufacturing  Development  lEMDI 
Cost.  EMD  follows  Demonstration  and  Validation  of  a 
modification  and  includes  the  costs  associated  with 
prototype  production,  testing  and  trial  installation.  EMD 
eosts  for  an  IMA  based  architecture  were  found  to  be 
similar  to  those  of  federated  systems  except  in  cases  where 
some  of  the  EMD  cost  had  already  been  paid  by  other 
upgrade  programs.  In  these  cases,  EMD  costs  were  half 
those  of  comparable  federated  systems.  EMD  costs 
represented  less  than  5%  of  the  total  life-cycle  cost  of  the 
modified  system. 

b.  Production  &  Deployment  (P«&D)  Cost.  P&D 
comprises  production  of  the  modification  kits  (Group  A 
and/or  Group  B),  delivery,  installation  and  disposal.  Total 
P&D  cost  was  found  to  be  similar  for  both  IMA  and 
federated  architectures.  These  eosts  accounted  for 
approximately  85%  of  the  modified  system’s  total  life- 
cycle  cost. 

c.  Organization  &  Support  tOASI  Costs.  Determining 
O&S  costs  was  particularly  difficult  due  to  the  many 
unknowns  which  could  not  be  resolved  until  actual 
manufacturing  had  been  started.  Nevertheless,  total  O&S 
costs  were  found  to  account  for  less  than  1 0%  of  the 
overall  project  life-cycle  cost  of  the  modification.  It  was 
most  important  during  this  stage  to  remember  that  the 
studies  had  to  compare  standardized  and  open  IMA 
architectures  with  standardized  and  open  federated 
architectures  also  of  the  latest  technology. 

d.  Future  Modification  Costs.  Future  operational 
requirements  and  cost  reductions  are  as  hard  as  ever  to 
predict.  In  addition,  there  are  many  uncertainties 
surrounding  future  missions  and  the  threats  to  be  faced. 
IMA  systems  offer  some  solutions  to  supportability  issues 
primarily  because  future  upgrades  should  be  cheaper  and 
easier  to  embody.  Figure  5  illustrates  that  even  when  the 
life-cycle  cost  study  indicates  that  IMA  will  not  be 
particularly  beneficial,  the  significantly  reduced  cost  of 
future  upgrades  can  make  a  great  difference  to  the  viability 
of  the  upgrade.  This  benefit  is  based  on  the  fact  that  much 
of  the  IMA  hardware  and  software  is  accessible  and 
reconfigurable  and  could,  therefore,  in  some  cases  be 
utilized  to  provide  all  or  part  of  the  new  capability.  As 
more  information  intensive  functions  such  as  combat 
identification,  target  recognition  and  battlefield 
management  are  demanded,  the  value  of  central  processing 
becomes  more  apparent.  Obtaining  raw,  processed,  or 
corroborative  data  from  an  integrated  system  would  be 
faster,  easier,  and  cheaper  than  establishing  a  similar 
capability  from  dispersed  federated  systems.  If  available, 
using  spare  capacity  in  the  IMA  rack  would  be  less  costly 
than  fitting  a  new  black-box  federated  unit.  It  has  been 
demonstrated  that  for  some  modifications  complex  new 
functions  or  capabilities  could  be  provided  by  modification 
to  the  software  alone.  One  recent  study  illustrated  the 
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savings  achievable  with  IMA  systems.  The  study  showed 
the  total  cost  of  introducing  one  new  communications 
function  to  an  aircraft  with  a  modem  federated  solution 
would  cost  $92k  per  aircraft.  To  introduce  that  same 
capability  as  an  integral  part  of  an  existing  IMA  system 
would  cost  only  $53k  per  aircraft.  Furthermore,  a  new 
function  (TACAN)  was  provided  at  almost  no  additional 
cost,  allowing  the  old  system  to  be  removed  to  save  weight 
and  provide  space.  In  addition,  the  O&S  cost  of 
supporting  the  federated  system  was  calculated  to  be  $47k 
per  aircraft  whereas  the  IMA  solution  would  cost  just  over 
$4k  per  aircraft.  Many  additional  examples  of  substantial 
savings  show  that  once  the  up-front  cost  had  been  paid  the 
future  costs  of  maintenance  and  modification  could  be 
substantially  reduced. 

6.3.2.  Weight  and  Volume.  The  weight  saving  of  IMA 
systems  depends  on  many  factors  not  least  of  which  would 
result  from  any  need  to  provide  liquid  cooling.  As  electronics 
become  more  compact  the  problem  of  dissipating  the  higher 
temperatures  becomes  more  pressing.  Providing  any  kind  of 
cooling  on  aircraft  is  expensive  and  an  unwelcome 
maintenance  penalty.  High  operating  temperatures  decrease 
reliability.  In  comparing  architectures,  it  was  shown  that  IMA 
had  a  density  approaching  1,000  kg/m3.  IMA  equipment  racks 
could  therefore  weigh  significantly  more  than  their  federated 
counterparts  and  may  require  structural  modification  to  the 
host  aircraft  to  support  the  additional  weight  over  the  design 
envelope.  Equivalent  federated  systems  would  have  lower 
densities  and  greater  weight  due  to  the  larger  number  of  parts, 
boxes,  eonnectors  and  wiring. 

6.3.3.  Reliability.  Many  design  aspects  of  IMA  indicate  a 
much  greater  reliability  than  federated  architectures.  The 
ability  to  reconfigure  IMA  architectures  using  software  means 
that  any  under-utilized  asset  could  perform  the  function 
required  thereby  maximizing  efficieney  and  enabling 
continued  operation  following  failures.  By  modeling  the 
varying  demands  of  the  different  phases  of  flight  and  missions 
the  optimal  utilization  of  each  asset  can  be  determined.  Fewer 
modules  are  required  as  the  utilization  rate  of  the  resources 
available  is  much  higher.  IMA  systems,  therefore,  have  fewer 
unique  parts. 

6.4.  Key  Factors.  The  factors  which  most  affected  the 
outcome  of  the  studies  and  should  therefore,  be  carefully 
eonsidered  before  undertaking  similar  studies,  were  as  follows; 

a.  Number  of  aircraft  and  aircraft  types.  Across  how 
many  aircraft  and  aircraft  types  could  the  costs  of 
modification  be  spread?  The  same  architecture  could  be 
fitted  to  a  variety  of  different  aircraft  giving  commonality 
across  fleets.  Not  all  aircraft  need  to  have  all  functions. 

b.  Number  of  functions,  technical  sophistication  and 
complexity.  Choosing  systems  with  common 
functionality  enables  the  greatest  benefit  of 
reconfigurability  to  be  maximized.  The  more  functions  to 
be  upgraded  the  greater  the  viability.  Sophisticated  and 
complex  functions  can  provide  less  demanding 
functionality  at  little  additional  cost  by  utilizing  spare 
capacity.  Selecting  basic  avionics  functions  would  limit 
the  benefits  of  the  new  architecture. 

c.  Environmental  requirements.  Although  federated 
systems  normally  require  some  kind  of  air  cooling,  IMA 


systems  can  be  so  densely  packed  as  to  require  liquid 
cooling.  Providing  even  limited  liquid  cooling  is  a  major 
cost  and  engineering  concern  that  can  make  even  the  most 
viable  new  architecture  unaffordable.  The  need  for  liquid 
cooling  should  therefore  be  avoided  if  possible. 

d.  Weight,  volume,  and  density.  New  electronic 
modules  mounted  in  racks  significantly  reduce  the  overall 
volume  taken  up  by  avionics  systems.  However,  this 
increased  density  can  overstress  the  structure  in  the  area 
traditionally  used  to  house  avionics.  Strengthening  the 
structure,  if  required,  can  be  prohibitively  expensive  as  this 
alone  can  exceed  the  total  cost  of  the  program. 

e.  Single  or  multiple  racks.  Integrating  all  the 
electronics  into  one  small  package  may  not  be  physically 
possible  due  to  a  lack  of  space.  It  is  possible  to  use  more 
than  one  rack,  but  as  the  number  increases  the  dependence 
on  the  reliability  and  integrity  of  high-speed  interconnects 
increases  and  this  adversely  affects  reliability.  Using  more 
than  one  rack  could  also  lead  to  interesting  problems  for 
calculating  the  reliability  of  modules  which  might  be  fitted 
in  several  different  locations  during  their  lifetime.  For 
example,  calculating  the  predicted  reliability  for  a  module 
that  might  spend  some  of  its  life  in  the  nose  of  an  F-1 5  and 
some  above  an  engine  in  an  F-1 6  could  be  complicated  due 
to  the  effects  of  the  different  environments.  The  physical 
problems  of  introducing  IMA  racks  into  small  fighter 
aircraft  are  significant  and  could  prove  to  be  prohibitively 
expensive. 

6.5.  Whilst  the  outcome  of  any  analysis  would  be  most 
affected  by  the  above  factors  the  selection  of  functions  would 
be  of  paramount  importance.  Figure  6  shows  2  cases  studied. 
The  first  case  considered  integrating  systems  not  suited  to  IMA 
as  they  had  little  functionality  in  common  and  the  airframe  was 
a  small  fighter.  The  second  case  considered  systems  which 
could  share  resources  and  the  airframe  was  suitable  for 
accepting  the  IMA  rack.  The  point  at  which  the  crossover 
occurs  will  depend  on  all  of  the  foregoing  factors. 

6.6.  Software.  Estimating  the  cost  of  initially  providing  and 
then  maintaining  software  for  both  IMA  and  federated  systems 
is  difficult  because  of  the  need  to  define  the  system  in  detail 
before  an  accurate  guess  can  be  made  of  the  software 
functionality  required.  Due  to  the  complexity  of  IMA  software 
and  its  software  control  of  all  the  available  assets,  it  would 
probably  prove  more  expensive  to  develop.  However,  IMA 
could  unleash  the  real  power  of  software  as  all  data  and 
resources  would  be  accessible  to  the  controller.  With  this  extra 
power  comes  greater  burdens  in  integration  and  testing. 
Research  shows  that  software  changes  are  made  at  a  rate  of 
about  10%  per  year.  Of  these  changes:  5-10%  are  corrective  in 
nature  (fixing  bugs);  30-40%  are  needed  to  adapt  the  software 
to  take  account  of  new  hardware;  and  50-60%  are  changes  to 
introduce  modifieations  and  improvements.  The  maintenance 
and  support  of  software  once  provided  is  likely  to  be  very 
similar  for  either  IMA  or  federated  systems. 

7.  WHAT  ARE  THE  SCIENCE  AND  TECHNOLOGY 
DEVELOPMENTS  WHICH  COULD  MAKE  A 
SIGNIFICANT  IMPACT  ON  AVIONICS  UPGRADES? 

7.1.  Electronics  packaging  and  cooling  technology.  The 
manner  by  which  electronics  are  packaged  and  cooled  plays  a 
crucial  role  in  upgrading  aging  aircraft  avionics  as  this 
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technology  determines  the  weight,  cost,  reliability,  and 
performance  of  the  installed  avionics.  Indeed,  this  subject  was 
of  sufficient  importance  that  the  AGARD  Avionics  Panel 
devoted  an  entire  symposium  to  the  subject  in  1994  (Ref  1). 
The  subject  is  so  important  because  there  is  an  enormous 
amount  of  relatively  low  cost  electronics  technology  which 
could  be  used  for  airborne  applications  if  the  technology  could 
be  packaged  and  cooled  to  withstand  the  severe  temperature 
and  vibration  environments  found  on  airborne  platforms. 
Invariably,  the  measures  taken  to  protect  the  electronics  result 
in  exorbitant  increases  in  cost  and/or  dramatically  reduced 
performance.  In  that  the  processing  speed  of  the  subsystems 
using  microprocessor  chips  requires  their  close  proximity  to 
minimize  transmission  time,  it  is  readily  apparent  that  severe 
cooling  problems  can  result  from  the  use  of  large  quantities  of 
these  high  performance  chips  in  the  close  confines  of  tactical 
aircraft.  The  Semiconductor  Industry  Association  (Ref  2) 
projects  a  400%  improvement  in  the  on-chip  clock 
performance  of  high  performance  chips  over  the  next  15  years. 
Over  the  same  period  of  time,  the  cost  per  transistor  will 
decrease  by  500%  and  the  heat  to  be  dissipated  in  the  heat 
sinks  for  these  high  performance  chips  will  increase  from  80  to 
180  watts  per  chip.  Air  cooled  avionics  can  generally  tolerate 
40-70  watts  heat  dissipation  for  each  Standard  Electronic 
Module  size  E  (SEM-E).  As  we  can  easily  fit  10  or  mofe  chips 
on  a  SEM-E  module,  we  approach  1  kilowatt  dissipation  with 
today’s  commercial  off  the  shelf  (COTS)  technology.  So  the 
science  and  technology  problem  is  how  to  make  use  of 
relatively  inexpensive  and  very  high  performance  chips  on 
tactical  fighter  aircraft  without  using  heavy  and  costly  cooling 
systems.  Another  tact,  is  the  development  of  light  weight,  low 
cost,  high  reliability  electronics  cooling  concepts.  Work  on 
heat  pumps  may  prove  satisfactory  for  at  least  small  cooling 
loads  (e.g.,  1-2  kW). 

7.2.  High  temperature  semiconductor  technology.  The 

high  heat  dissipation  anticipated  with  high  performance  CMOS 
processing  chips  poses  a  severe  packaging  and  cooling 
problem  as  mentioned  above.  The  junction  temperatures  for 
these  transistors  must  be  kept  below  120OC.  One  solution  is  to 
use  higher  temperature  semiconductor  devices.  Silicon  on 
insulator  (SOI)  technology  will  withstand  250^0  temperatures 
and  silicon  carbide  devices  will  withstand  400^0  junction 
temperatures.  However,  any  solution  will  be  enormously 
expensive  to  realize  as  many  new  materials  and  manufacturing 
processes  must  be  developed.  The  investments  required  will 
only  result  if  it  is  found  that  such  devices  are  of  commercial 
interest  and  that  does  not  appear  likely  in  the  foreseeable 
future. 

7.3.  Low  Power  Electronics.  Another  technology  offering 
promise  for  reducing  heat  is  the  activity  under  the  general 
heading  of  low  power  electronics.  The  United  States  Defense 
Advanced  Research  Projects  Agency  (DARPA)  (Ref  3)  has 
initiated  a  series  of  efforts  to  develop  a  new  class  of  electronic 
systems  which  dissipate  less  than  1%  of  the  power  of  current 
systems  without  a  performance  penalty.  The  problem  of  power 
dissipation  is  quickly  becoming  a  critical  issue  for  military  and 
commercial  products.  In  the  commercial  sector,  the  demand 
for  portable  products  generally  requires  that  the  product 
dissipate  less  than  5W  because  of  battery  and  cooling 
problems.  Similarly,  desktop  PCs  dissipating  more  than  about 
30W  pose  difficult  problems  because  of  the  expense  of  cooling 
and  packaging.  The  program  addresses  five  technology  areas 
including  silicon-on-insulator  (SOI)  substrates,  new  device 
structures,  manufacturing  processes  for  low  voltage  circuits. 


architectures  for  low  voltage  circuits,  and  application 
demonstrations. 

7.4.  Upgraded  STANAG  3838  (MIL  STD  1553)  data  bus. 
MIL  STD  1553  data  buses  have  proven  to  very  successful  for 
airborne  applications  and  have  been  installed  on  a  wide  variety 
of  military  and  commercial  aircraft.  As  we  now  consider  how 
to  upgrade  the  avionics  systems  on  these  aging  aircraft,  it  is 
invariably  found  that  increased  bandwidth  and  data  rates  are 
needed  between  the  major  units  of  the  avionics  system.  As 
pointed  out  elsewhere  in  this  paper,  it  is  extremely  costly,  and 
perhaps  impossible  in  some  circumstances,  to  install  additional 
cables  for  the  needed  performance.  It  may  be  possible  to 
develop  technology  which  would  permit  the  use  of  installed 
twisted  pair  cables  for  transmitting  much  greater  data  rates  - 
perhaps  as  much  as  100  times  the  1  MHz  data  rates  for  which 
these  cables  were  originally  designed.  A  new  protocol  would 
be  needed  together  with  the  implementing  electronics,  but  the 
fact  that  these  cables  are  installed  in  so  many  aircraft  and  the 
enormous  cost  of  new  cable  installation  could  make  this  a 
viable  solution  for  at  least  some  applications.  Many 
challenging  technology  problems  must  be  resolved  including 
the  signal  loss  through  the  cables  and  the  electromagnetic 
compatibility  problems  which  may  result  from  signal  radiation 
from  these  cables. 

7.5.  Another  technology  problem  which  could  prove  to  be  a 
major  factor  for  upgrading  avionics  is  the  notion  of  bridges 
between  MIL  STD  1553  data  buses  and  higher  performance 
buses  in  development  today  and  in  the  future.  It  appears  that 
programmable  interface  modules  (perhaps  field  programmable 
gate  arrays  (FPGA))  which  could  be  programmed  to  interface 
the  installed  MIL  STD  1553  data  bus  with  a  wide  variety  of 
other  data  buses  could  simplify  the  integration  of  new 
technology  with  the  older  installed  technology. 

7.6.  Analog  to  digital  (A/D)  converters.  Digitization  of 
electronic  systems  is  very  effective  in  reducing  the  cost  and 
size  of  avionics  as  well  as  improving  performance  and 
reliability.  The  single  most  critical  impediment  to  increased 
digitization  is  A/D  converter  technology.  As  rapidly  as  A/D 
converters  can  be  improved  with  respect  to  bandwidth, 
resolution  and  cost,  they  will  be  applied  to  avionics 
applications.  Current  technology  will  permit  the  1998 
operational  deployment  of  A/D  converters  with  12  bit 
resolution,  120  mega  samples  per  second  (MS/s)  for  direct 
sampling  at  second  IF  frequencies  of  60  MHz.  Direct 
sampling  at  200  MHz  (12  bits,  120  MS/s,  120  MHz 
bandwidth)  should  be  possible  by  the  year  2000.  This 
technology,  together  with  commercial  microwave  monolithic 
integrated  circuit  (MMIC)  RF  and  IF  circuits  will  enable 
substantial  cost,  weight,  and  size  reductions  in  avionics 
subsystems.  For  example,  technology  is  currently  available  to 
support  the  development  of  a  radar  receiver  channel  which  will 
fit  on  one  SEM-E  size  card,  will  dissipate  approximately  70 
watts  of  power,  and  will  cost  approximately  $15,000.  Two  of 
these  cards  will  replace  two  50  pound  boxes  in  modem  jet 
fighters. 

7.7.  Software  reuse  technology.  With  the  dramatic  shift  to 
digital  avionics  for  new  and  upgrade  applications,  there  is  and 
will  continue  to  be  profound  implications  on  the  development 
of  software  for  the  systems.  The  single  largest  impediment  to 
accomplishing  an  avionics  upgrade  is  often  the  cost  of 
rewriting,  testing  and  integrating  the  old  software  for  the  new 
computer.  Unless  this  cost  can  be  dramatically  reduced,  many 
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avionics  upgrade  programs  will  not  get  beyond  the  point  of 
being  just  an  interesting  idea.  Many  military  avionics  systems 
introduced  into  operation  in  the  1970’s  and  1980’s  used  the 
MIL  STD  1750A  instruction  set  architecture  to  minimize  the 
logistic  impact  of  supporting  numerous  systems.  Most  of  the 
software  was  programmed  in  assembly  language  or  MIL  STD 
1589  (JOVIAL).  However,  MIL  STD  1750A  permitted  user 
defined  input  /output  (I/O)  structures.  As  a  result,  each 
computer  system  has  a  unique  software  interface  compounding 
the  problem  of  finding  common,  low  cost  solutions.  When 
trying  to  avoid  rewriting  all  new  software,  alternative 
approaches  for  reusing  the  existing  software  generally  fall  into 
three  general  categories.  The  most  expensive  and  most 
comprehensive  approach  is  to  re-engineer  (Ref  4)  the  old  code 
into  a  new  higher  order  language  (HOL)  using,  where  possible, 
automated  software  translators  and  documentation  tools.  The 
advantages  of  this  approach  include  the  fact  that  the  end 
product  is  a  new  software  system  written  in  a  modem 
programming  language  and  new  documentation.  Another 
advantage  is  that  needed  code  upgrades  can  be  readily 
incorporated  in  the  new  system.  Disadvantages  include  the 
need  to  test  and  validate  the  entire  software  system.  This  is  a 
very  expensive  activity  that  few  programs  can  afford.  The 
least  expensive  approach  involves  the  use  of  hardware  or 
software  emulators  to  rehost  the  old  software  in  a  new 
processor.  This  approach  is  not  very  efficient  relative  to  using 
the  new  processor  and  makes  no  improvement  in  the  old  code. 
However,  it  is  a  relatively  inexpensive  and  quick  solution.  An 
intermediate  approach  in  terms  of  cost  and  flexibility  is  the 
notion  of  a  “software  wrapper”.  In  the  new  processor,  an 
object  oriented  programming  language  is  used  and  the  old 
software  system  is  “wrapped”  by  additional  interface  software. 
The  legacy  software  is  simply  treated  as  an  object  in  the  new 
software  architecture.  Science  and  technology  development  is 
needed  in  all  three  approaches,  particularly  software 
reengineering  and  software  wrappers.  Particular  attention 
needs  to  be  focused  on  software  errors  by  providing  adequate 
fault  tolerance  to  assure  that  errors  do  not  result  in  mission 
failures. 

7.8.  Plug  and  play  capability.  The  “plug  and  play”  feature 
available  from  the  Microsoft  ®  Windows®  95  operating 
system  for  personal  computers  is  an  intriguing  concept  to 
consider  for  avionics  applications.  Imagine  the  cost  impact  of 
simply  plugging  a  new  module  -  say  an  improved  Global 
Positioning  System  receiver  -  into  an  avionics  rack  and  being 
automatically  hardware  and  software  compatible  with  the 
installed  system. 

7.9.  Simulation  and  modeling  technology.  Simulation  and 
modeling  technology  will  play  a  major  role  in  the  development 
of  avionics  upgrades  (as  well  as  avionics  systems  for  new 
aircraft).  High  fidelity  simulation  models  are  becoming 
available  which  will  permit  the  economical  and  rapid 
evaluation  of  many  design  approaches  to  select  the  correct 
solution.  These  models  will  faeilitate  the  development, 
integration  and  testing  of  software  prior  to  expensive 
fabrication  of  the  hardware.  The  VHSIC  High  Order  Design 
Language  (VHDL)  (Ref  5)  will  permit  the  specification  of  all 
essential  teehnical  aspects  of  electronic  circuits  and  thus  permit 
the  re-manufacture  of  obsolete  parts  in  current  technology. 

8.  IMPACTS  ON  AVIONICS  MANUFACTURING  BASE 

Without  doubt,  the  IMA  concept  will  have  a  significant  impact 
on  the  avionics  industrial  base.  Manufacturers  who  have 


traditionally  developed  specific  systems  or  subsystems  such  as 
radar,  electronic  warfare,  communications,  and  navigation  now 
find  that  the  avionics  suite  of  future  aircraft  and  perhaps 
modifications  to  avionics  on  aging  aircraft,  will  be  built  around 
architectures  which  are  functionally  independent.  In  the  limit, 
it  is  entirely  possible  to  consider  avionics  suites  where  the 
functional  uniqueness  of  an  avionics  suite  will  only  be  evident 
in  the  software  which  controls  the  system.  All  hardware 
attributes  of  the  system  may  be  multi-functional  in  nature  and 
time-shared  between  the  many  functions  which  the  avionics  is 
required  to  perform.  These  changes  will  have  a  profound 
impact  on  avionics  manufactures  who  are  specialized  in 
avionics  subsystems  for  specific  functions.  This  is  a  cause  for 
anxiety  and  optimism  depending  on  your  point  of  view.  The 
IMA  paradigm  will  certainly  create  many  opportunities  and 
needs  for  new  products.  These  products  will  provide 
significant  new  improvements  in  avionics  functionality  while 
reducing  the  cost  per  function.  These  changes  are  occurring  in 
a  period  of  time  where  defense  budgets  are  shrinking 
dramatically  and  thereby  reducing  the  opportunities  for 
military  procurements  of  all  kinds,  including  new  or  upgraded 
avionics  suites.  Avionics  is  unique  in  the  measure  of 
performance  upgrade  per  dollar  which  can  be  achieved  using 
modern  electronics  technology.  However,  in  order  to  realize 
the  enormous  potential  of  integrated  approaches  for  achieving 
greater  performance  per  dollar  and  per  unit  volume  and 
weight,  a  new  planning  paradigm  must  be  used  for  avionic 
upgrades.  A  broader  look  across  all  of  the  traditionally  unique 
avionic  functions  must  be  taken  relative  to  upgrading 
performance  or  dealing  with  obsolescence  and  bad  actors.  The 
needs  of  the  entire  fleet  must  be  considered  to  take  full 
advantage  of  the  economies  of  scale  and  reduced  costs  which 
result  from  a  fewer  number  of  common  parts.  The  cunent 
notion  that  most  of  the  avionics  are  unique  must  be  upgraded 
as  if  unique,  must  be  abandoned.  However,  even  with  the 
performance  per  dollar  advantage  that  avionics  technology 
enjoys  over  other  technologies  (structural,  propulsion, 
materials,  etc.)  which  may  be  applied  to  extend  the  useful 
service  of  aging  aircraft,  a  change  in  design  approach  must  be 
found  to  reduce  the  high  cost  of  avionics  upgrades.  Cost 
estimates  for  many  essential  avionics  upgrades  are  prohibitive 
and  simply  will  not  be  accomplished.  This  indeed  will  have  a 
profound  impact  on  the  avionics  industrial  base! 

9.  CONCLUSIONS 

The  dramatic  reduction  in  defense  spending  in  NATO 
countries  will  result  in  fewer  new  military  aircraft.  Currently 
fielded  avionic  systems  will  need  to  remain  in  service  for 
longer  than  originally  envisaged.  Existing  systems  suffer  from 
the  obsolescence  of  spare  parts,  poor  reliability  and  difficulty 
in  upgrading  due  to  their  architecture  and  complexity.  The 
advantages  of  IMA  offers  the  opportunity  of  overcoming  the 
limitations  of  current  systems  whilst  providing  growth  capacity 
and  performance  to  meet  future  unforeseen  requirements.  IMA 
can  be  cost  effective  provided  the  right  factors  are  considered. 
Selecting  functions  with  similar  functionality  requirements 
produces  the  most  viable  case  for  IMA.  IMA  can  be  cheaper 
to  modify  than  alternative  architectures.  The  Science  and 
Technology  community  could  directly  influence  the  viability 
of  advanced  architectures  by  pursuing  advances  in  several 
critical  areas  including  software,  backplanes,  packaging  and 
cooling.  IMA  provides  challenges  and  opportunities  for  the 
avionics  manufacturing  base.  It  will  also  provide  rewards  for 
successful  companies. 
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SUMMARY 

A  look  into  the  future  of  avionic  architectures  over  the  next 
twenty  years  is  presented  by  extrapolating  past  evolutionary 
trends,  projecting  future  military  needs  and  projecting  the 
availability  of  advanced  architectural  building  blocks. 

The  basis  for  this  forecast  is  drawn  from  the  hypotheses  that: 
1)  the  physical  and  functional  attributes  of  architectures 
evolve,  even  though  the  building  block  technologies  often 
undergo  revolutionary  changes;  hence,  extrapolation  of  past 
architectural  trends  provides  a  good  “first  cut”  look  at  the 
future,  2)  basic  changes  in  architecture  are  driven  by  network 
bottlenecks  resulting  from  the  application  of  advanced 
technology  building  blocks  that  are  used  to  improve  situation 
awareness;  hence  an  understanding  of  forces  driving 
improvements  in  situation  awareness  and  what  devices  future 
architects  will  have  at  their  disposal  helps  frame  the 
processing  and  interconnect  requirements  (and  hence  the 
architecture)  and  3)  cost  containment,  even  cost  reduction  of 
avionics  systems,  will  be  the  dominant  driver  for  future 
architectures;  hence,  any  form  of  physical  or  functional 
integration  that  reduces  cost  also  helps  define  future 
architectures. 

Conclusions  drawn  from  this  paper  are:  1)  architecture 
changes  resulting  from  avionics  updates  will  continue  to  be 
evolutionary,  with  new  building  blocks  and  network  designs 
“grown  onto”  the  existing  infrastructure,  2)  architectural 
extensions  for  retrofits  will  take  the  form  of  “bridging” 
network  interface  circuitry  that  will  interconnect  advanced 
COTS-based  networks  and  processors,  3)  the  drive  for 
improved  situation  awareness  will  force  architectures  to 
increasingly  support  signal  processor-based  networks  that  will 
be  dominated  by  several  gigabit/second  streaming  data;  as  a 
result,  switch-based,  point-to-point  links  will  be  the  primary 
means  of  system-level  interconnections,  with  bus-based 
networks  being  used  mostly  for  control  and  message  passing 
at  the  backplane  level,  4)  for  the  first  time,  the  application  of 
new  photonics-based  building  blocks  to  new  avionics  designs 
will  eventually  allow  the  avionics  architect  the  design 
freedom  to  physically  and  functionally  locate  computing 
assets  at  space-available  locations  without  performance 
penalty,  5)  highly  digital,  “functionally  integrated,  physically 
distributed”  systems  will  emerge,  with  the  co-habitation  of  RF 
analog  and  digital  pre-processing,  signal  and  data  processing 
modules  existing  within  the  same  module-based  enclosure.  A 
physically  distributed,  unified  network  will  result,  with  a 
unified  interconnect  network  across  RF,  IF,  data  and  signal 


processing  modules,  6)  analog  photonics  will  emerge  to 
challenge  RF  electrical  signal  distribution,  filtering  and 
frequency  conversion  functions,  7)  the  digital  boundary  will 
move  closer  to  the  RF  apertures;  digital  CNI  (up  to  2  Ghz) 
systems  and  a  mostly  digital-based  radar  warning  and  radar 
systems  will  eventually  replace  more  costly  analog  designs,  8) 
within  the  next  15-20  years,  a  new  “fourth  generation” 
architecture  will  emerge  that  will  embody  the  features 
described  above.  The  dominant  feature  of  this  projected 
architecture  is  the  similar  interconnect  structure  that  both 
analog  and  digital  avionics  will  assume.  As  a  result  of  the 
increasing  digitization  of  analog  functions  and  the  availability 
of  high  speed  networks,  the  classical  physical  boundaries  of 
avionics  will  almost  vanish.,  9)  architectures  will  be  driven 
and  constrained  by  the  mandate  that  designs  be  made  open 
and  commercial-based  to  the  greatest  extent  possible.  This 
trend  will  profoundly  affect  future  architectures  in  that 
network  protocols,  processors  and  software  operating  systems 
will  likely  change  with  time.  Coping  with  this  changing 
environment  will  require  the  expanded  use  of  design  tools, 
descriptive  design  languages  and  programmable  interfaces. 
Furture  architectures  must  be  designed  for  change  at  the 
outset. 


1  INTRODUCTION 

Predicting  the  future  a  avionics  architectures  requires  many 
assumptions  about  the  direction  of  military  priorities  and 
missions,  budgetary  constraints  and  the  availability  of  both 
commercial  and  military-unique  building  blocks.  More 
importantly  however  is  the  realization  that  architectures 
evolve  and  hence,  are  predictable  to  the  extent  that  an 
understanding  of  cause  and  effect  can  be  achieved.  That  is,  a 
future  architecture  “end  state”  resulting  from  any  projection 
must  be  consistent  with  predictions  resulting  from  an 
extrapolation  of  past  architectural  trends,  modified  to  the 
extent  that  the  controlling  influences  can  be  predicted  to 
change.  These  major  controlling  influences  will  first  be 
diseussed  and  then  overlayed  onto  the  motivating  reasons  why 
architectures  have  changed  in  the  past.  Coupling  this  analysis 
with  the  availability  of  system  building  blocks,  the  resulting 
architectures  will  be  predicted. 

This  paper  assumes  the  following  pervasive  trends  and 
logically-derived  implications  will  drive  future  architectures: 

1)  Mission  Needs:  The  author  believes  that  future  avionics 
suites  will  continue  to  be  enhanced  by  off-board  sources  of 
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information  in  order  to  improve  real-time  situation  awareness 
against  mobile  threats  and  targets.  Another  projected  mission 
need  is  the  long-time  support  of  avionics  in  an  austere  base 
environment.  Implications:  The  so-called  “Information 
Warfare  Era”  will  eventually  have  profound  effects  on  the 
way  sensor  systems  are  architected.  Avionic  architectures  will 
be  viewed  as  a  node  in  a  much  larger  global  or  theatre-level 
real-time  network  architecture.  This  nodal  architecture  will 
need  to  receive  off-board  targeting  or  sensory  data  and  then 
fuse/integrate  this  information  with  on-board  assets. 
(Similarly,  this  node  may  be  called  on  to  transmit  requested 
information  onto  the  global  network)  Off-board  information 
must  be  viewed  as  if  it  were  derived  from  a  collection  of 
virtual  on-board  sensors.  However,  due  to  the  diversity  of  off- 
board  information  and  the  unpredictability  of  its  availability 
for  a  given  theatre  of  operation,  the  architecture  must  be 
extremely  flexible  in  its  ability  to  expand  or  contract  its 
processing  and  data  distribution  tasks.  Similarly,  mission- 
custom  palletized  avionics  are  projected  to  become  more 
commonly  used  in  the  future  and  will  require  extreme 
architecture  flexibility.  In  addition,  the  growing  need  for 
affordable  real-time  situation  awareness  and  the  move  to 
digitizing  RF  functions  closer  to  the  aperture  will  increasingly 
lead  to  “sensor-system  driven”  architectures,  similar  to  digital 
processor  architectures.  These  systems  will  be  characterized 
by  multi-gigabit  per  second  networks  that  interconnect 
streaming  data  between  sensor  and  processing  assets  using 
switches.  Finally,  the  other  major  mission  emphasis  area  that 
is  expected  to  drive  architectures,  that  of  increased  sortie 
generation  from  austere  bases  implies  that  future  avionics 
architectures  will  be  required  to  support  system-level  on¬ 
board  testing  and  fault-tolerant  reconfigurability  to  allow 
system  performance  to  gracefully  degrade  until  maintenance 
actions  can  be  taken. 

2)  Cost  containment.  The  linear  increase  in  the  percentage 
fly-away  cost  of  avionics  since  the  1 960s  has  reached  the  30- 
40%  level  for  fighter  aircraft.  Support  costs  have  followed  a 
similar  trend.  Sensors  account  for  about  two-thirds  of  the  cost, 
with  processors  and  networks  being  about  20%  and 
controls/displays,  stores  management  and  vehicle 
management  functions  accounting  for  only  about  4-6%  each. 
It  would  appear  that  this  trend  is  non-supportable  and  must  be 
hatted.  One  approach  currently  being  pursued  to  lower 
avionics  cost  is  to  to  use  commercial  off  the  shelf  (COTS) 
hardware  and  software  to  the  maximum  degree  practicable  and 
to  reduce  the  use  of  unnecessary  military  standards  in  favor 
of  lower  cost  “Best  Commercial  Practices”.  This  movement 
for  lower  cost  avionics  has  resulted  in  a  new  US  Department 
of  Defense  Initiative  to  pursue  the  adoption  of  Open  System 
Architectures.  Under  this  Initiative,  commercial  industry 
standards  are  used  to  describe  the  attributes  of  the 
architecture  so  that  open,  non-proprietary  information  can  be 
used  to  promote  competition  and  enable  the  use  of  COTS 
building  blocks  in  order  to  reduce  cost.  Further,  various 
programs  are  underway  to  reduce  sensor  costs  though  the  use 
of  multi-function  hardware,  increased  RF  digitization  and  the 
use  of  line  replaceable  modules. 


Implications:  Since  the  COTS  market  is  extraordinarily 
dynamic,  with  new  products  being  released  every  18-24 
months  and  new  commercial  “standards”  constantly  changing, 
obsolete  processor  and  network  parts  will  result  in  the 
“building  codes”  of  the  architecture  changing  over  time.  For 
example,  we  can  no  longer  depend  on  building  blocks  being 
interconnected  by  MIL  STD  1553  or  some  other  standard 
network  protocol,  nor  can  we  expect  standard  processors,  such 
as  MIL  STD  1750  to  be  in  existence  in  the  far  future. 
Commercial  networks  and  processors  having  a  4-5  year  parts 
availability  will  eventually  become  common  place.  For 
currently-fielded  avionics,  1553  networks  will  likely  be 
bridged  over  to  new  COTS  networks  and  processors,  with 
older  military-based  equipment  being  gradually  removed  with 
time. 

In  some  ways,  history  is  repeating  itself  in  that  we  are 
returning  to  the  1960-70  era  of  proliferation  of  hardware  and 
software  designs.  Some  would  argue  that  the  main  difference, 
that  of  using  COTS  instead  of  custom  military  designs,  results 
in  even  more  flux  in  that  the  COTS  parts  obsolescence 
problem  and  the  rapid  pace  of  market  place  changes  further 
increases  the  integration,  retrofit  and  and  repair  problems. 

Two  messages  relating  to  COTS  are  clear  however.  First,  the 
military  has  little  choice  in  the  matter  because  of  our  minute 
presence  in  the  microcircuit  market  and  our  dwindling 
budgets  (about  1.5%  of  global  sales).  Second,  the 
technologies  that  are  causing  the  “problem”  will  also  bring 
the  solution.  That  is  to  say,  the  use  of  COTS  processors  will 
allow  the  extensive  use  of  automated  design  and  simulation 
tools.  Computer-based  simulation  tools  will  be  used  to  capture 
the  present  state  of  the  architecture  and  to  analyze  the  impact 
of  changes  so  that  the  proposed  use  of  various  COTS 
hardware  and  software  can  be  quickly  assessed  before  weapon 
system  commitment.  And  possibly  more  important,  automated 
computer-based  software  validation  tools  will  be  used  to 
reduce  costly  flight  testing.  Attributes  of  architecture  will  be 
automatically  encoded  into  VHDL  designs  for 
implementation. 

Further,  a  greater  reliance  on  programmable  interfaces  (vice 
custom  ASICS)  will  be  required  to  help  accommodate  COTS 
changes  at  the  network  level.  Field  programmable  gate  arrays 
(FPGAs)  will  be  increasingly  used  to  encode  protocol  and 
data  security  features.  VHDL  descriptions  of  network 
protocols  will  need  to  be  available  to  quickly  reprogram  these 
FPGAs.  It  will  be  mandatory  that  operating  system  software 
and  the  various  software  interfaces  that  separate  it  from  the 
hardware  be  developed  in  a  highly  modular  fashion  to  mask 
network  and  processor  changes  from  the  application  software 
to  avoid  costly  re-validation.  In  addition,  some  architectural 
building  blocks  such  as  preprocessors  which  have  previously 
been  considered  static  over  the  life  of  the  system  will  also 
need  to  be  implemented  in  FPGAs.  As  a  result  of  this  new  era 
of  uncertainty,  the  avionic  system  architect  will  find  himself 
increasingly  relying  on  computer-based  simulations,  data 
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bases  and  VHDL  routines  to  design  and  control  the  avionics 
system  design. 

The  drive  for  low  cost  and  the  desire  to  support  high  speed 
data  streams  will  also  lead  to  more  unified  networks  which 
have  fewer  stages  of  optical-electrical  interfaces  between  the 
system  network  and  the  backplane.  Not  only  will  hardware 
cost  and  weight  be  reduced,  but  less-complex  control  software 
will  be  possible  to  permit  system  connectivity  from  sensor, 
processing,  memory  or  display  modules.  Many  of  the 
concepts  of  integration,  sharing,  common  modules  and 
reconfiguration  that  have  been  successfully  applied  in  the 
digital  processing  realm  will  be  applied  to  RF  systems  in 
order  to  lower  sensor  cost  while  providing  architectural 
versatility  needed  to  exploit  off-board  information. 

3)  Technology  Building  Blocks:  Future  architectures  will  be 
shaped  by  significant  strides  being  made  in  both  COTS  and 
military  technologies.  In  general,  COTS  advances  that  will 
affect  military  avionics  are  being  made  in  the  digital 
processing  and  network  areas  in  response  to  the  vast  personal 
computer  market,  with  some  COTS  RF  circuits  from  the 
telecommunications  industry  recently  being  available  for  use. 
Figure  1  shows  the  massive  strides  being  made  in  COTS  data 
and  signal  processors.  Not  only  will  military  avionics  use 
these  products  with  proper  packaging  and  cooling,  but  the 
extremely  high  speed  processing  required  to  accomplish 
future  improvements  in  situation  awareness  will  be  feasible. 
Table  1  shows  both  the  data  rate  and  processor  projections 
needed  to  support  several  situation  awareness  enhancements 
for  the  2010  time  frame  era.  (Ref  1).  It  is  important  to  note 
that  these  are  conservative  forecasts  since  some  forecasts 
indicate  much  higher  data  rates  and  processing  speeds  being 
required  in  the  future. 

Table  2  shows  the  characteristics  of  current  digital  networks 
available  to  the  avionics  architect.  Note  that  these  networks 
are  generally  too  slow  to  meet  the  data  rate  projections  in 
Table  1  without  extensive  numbers  of  parallel  interconnects. 
Further  detail  regarding  emerging  photonic  networks  is 
shown  in  Table  3.  Although  photonic  networks  offer  the 
future  promise  of  achieving  the  needed  speeds  of  about  2-3 
gigabits/second,  this  table  shows  that  much  work  still  needs 
to  be  done,  particularly  in  reducing  the  cost  of  photonic 
components.  Under  a  Defense  Advanced  Research  Projects 
Agency  (DARPA)  project  beginning  in  early  1997,  digital 
photonics  building  blocks  in  this  speed  regime  will  be 
developed  for  availability  in  2000. 

Figure  2  shows  Harris  Corporation’s  projections  for  COTS- 
based  conventional  and  programmable  gate  arrays  that  will 
allow  protocol  and  preprocessor  changes  to  supportThe 
architecture  updates.  The  upper  line  in  the  Figure  shows  the 
maximum  advertised  size  of  conventional  (non¬ 
programmable)  gate  arrays,  the  next  lower  dotted  line  shows  a 
more  conservative  projection  for  conventional  gate  arrays  and 
the  lowest  dotted  line  shows  a  conservative  projection  of 
FPGA  technology.  The  top,  relatively  flat  curve  shows  an 


estimate  of  the  gates  needed  to  program  a  sophisticated  COTS 
protocol  such  as  Scalable  Coherent  Interface  (SCI).  Note  that 
the  Figure  shows  that  we  will  soon  have  the  capability  needed 
to  quickly  adapt  to  new  network  protocols  through  VHDL 
designs.  As  a  point  of  reference,  the  lower  curves  on  Figure 
2  show  the  number  of  conventional  gates  used  on  the  high 
speed  data  bus  (HSDB)  and  fiber  optic  transmitter  receiver 
(FOTR)  networks  shown  in  Table  2. 

The  impact  of  COTS  in  the  RF  sensor  arena  has  just  begun 
as  a  result  of  the  telecommunications  industry  which  will 
impact  military  communications  designs.  In  general,  lowering 
the  cost  of  RF  sensors  through  technology  will  require 
military-eustom  analog  and  digital  components.  The  most 
striking  change  in  RF  technology  will  be  the  increasing 
movement  of  A/D  conversion  towards  the  aperture  because 
digital  RF  processing  eliminates  costly  mixers,  oscillators  and 
amplifiers  while  providing  improved  performance.  A/D 
converters  that  can  provide  eight  bits  of  resolution  at  a  3 
gigasample/second  sampling  rate  have  been  built  and  several 
teehnology  programs  are  underway  to  increase  both  the 
resolution  and  the  sampling  rate.. 

Implications:  Future  architectural  building  blocks  will  be 
much  more  compact,  with  several  functions  previously 
accomplished  by  several  black  boxes  being  done  in  a  small 
box  or  module.  As  a  result,  dramatically  increased  signal 
processing  and  network  data  rates  will  result,  along  with  the 
need  for  highly  advanced  packaging  in  the  digital  sensor  area. 
Since  these  technologies  allow  improvements  in  situation 
awareness  (e.g.,  longer  detection  ranges  for  RF  sensors), 
weight  and  cost  savings  (e.g.,  elimination  of  expensive  analog 
mixers,  amplifies  and  filters)  and  will  allow  programmable 
adaptability,  the  author  believes  that  they  will  be  used 
extensively.  These  technologies  are  re-opening  the  argument 
whether  future  systems  will  be  distributed  or  integrated.  For 
example,  if  current  network  speed  limitations  could  be 
removed  by  the  use  of  multi-gigabit  per  second  photonic 
networks,  further  integration  of  pre-processor,  signal 
processor  and  data  processor  functions  could  be  centrally 
integrated  in  a  common  processor  rack  with  attendant  weight 
savings  and  increased  opportunities  for  sharing  of  processing 
assets.  On  the  other  hand,  the  increasing  low  cost  and 
functionality  of  microcircuits  (more  gates  on  a  chip)  suggests 
that  increased  dedication  of  functions  may  be  affordable  in  the 
future  in  order  to  exploit  some  of  the  advantages  of  federated 
architectures  (e.g.  less  complex  software,  improved  battle 
damage  tolerance,  tailored/higher  performance  designs,  more 
easily-aligned  vendor  responsibilities  and  accountability,  etc,). 

The  author  believes  both  views  have  merit  but  that  additional 
considerations  will  lead  to  the  conclusion  that  a  hybrid 
architecture  will  result.  Since  higher-level  fusion,  system 
health,  system  control,  reconfiguration,  display  and  stores  and 
vehicle  management  interface  functions  must  be  performed, 
an  integrated  processing  function  will  still  be  required. 
However,  there  is  no  reason  to  believe  that  this  funetion  must 
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be  physically  centralized,  nor  should  sensor  and  processing 
functions  necessarily  will  have  to  physically  or  functional 
separate  in  the  future.  The  rationale  to  support  these 
statements  flow  as  a  natural  evolutionary  step  in  the  history  of 
architectures.  This  history  is  described  below. 


dedicated  display,  with  the  aircrew  performing  the  integration 
function.  Point-to-point  (i.e.,  hard-wired)  electrical  links 
interconnected  sensors,  controls  and  displays  and  processors, 
which  were  initially  analog  computers.  Note  that  the  functions 
performed  by  these  single  thread  approaches  required  little 
processing  sophistication  and  low  data  rates. 


2  ARCHITECTURE  EVOLUTION 

Avionic  architectures  have  evolved  from  their  predecessor  as  a 
result  of  network  bottlenecks  caused  by  an  attempt  to  satisfy 
the  need  for  improved  situation  awareness  or  performance. 
Figure  3  shows  a  simplified  model  of  the  process  involved. 
Situation  awareness  improvements  are  enabled  by  the  addition 
of  improved  sensors  and  displays  and  made  possible  by 
advanced  digital  processing  capabilities.  Eventually,  a  state  is 
reached  where  the  current  physical,  functional  and  logical 
configuration  of  the  avionics  (i.e.,  the  architecture)  cannot 
continue  to  support  the  steadily  increasing  flow  of 
information  between  sensors,  processors  and  displays.  A 
network  bottlenect  occurs.  If  the  data  carrying  capacity  of  the 
system  interconnect  structure  can  be  cost  effectively 
upgraded  by  the  addition  of  additional  or  faster  networks,  the 
life  of  the  architecture  is  extended.  If  however,  a  new 
functional  and/or  physical  partitioning  results  that  requires  a 
fundamentally  new  network  design  to  remove  bottlenecks,  a 
new  architecture  class  evolves.  It  is  interesting  to  look  at  how 
the  characteristics  that  describe  the  architecture  have  evolved 
over  time  by  looking  at  several  trends  reflected  in  several 
Figures.  Figure  4  shows  an  exponential  increase  in  data  and 
signal  processing  capability  that  has  mainly  resulted  from  the 
addition  of  sensors  which  provided  improved  situation 
awareness.  Figure  5  shows  that  a  similar  growth  of  network 
rates  have  increased  over  time  for  several  military  aircraft. 
Note  the  Pace  Pace  projection  is  derived  from  a  composite 
estimate  from  several  contractor  sources  and  is  typical  of  the 
data  network  requirements  for  a  multi-role  fighter  in  the  2005- 
2010  time  frame.  Figure  6  shows  a  comparative  estimate  of 
how  the  processing  technology  growth  and  advanced 
packaging  capability  from  1990  to  the  year  2000  should 
manifest  itself  at  the  modular  avionics  level.  Note  that  a  ten¬ 
fold  decrease  in  module  count  is  predicted  for  twice  the 
processing  capability.  These  figures  illustrate  the  model 
shown  in  Figure  3,  viz.,  the  availability  of  advanced 
componentry  will  permit  the  drive  for  increased  situation 
awareness  to  be  satisfied,  but  at  the  expense  of  driving  up 
network  speeds  to  interconnect  sensors,  processors  and 
displays.  The  question  to  be  addressed  now  is  whether  the 
need  for  increased  network  speeds  shown  in  Figure  5  can  be 
met  with  existing  architectures  or  whether  a  new  one  is 
required  to  avoid  a  bottleneck. 

With  the  above  trend  data  in  mind,  we  are  now  in  a  better 
position  to  understand  the  motivation  behind  why 
architectural  configurations  have  changed  over  time  and,  in 
turn,  forecast  the  next  logical  evolutionary  step  (see  Figure  7). 
The  earliest  architecture,  that  of  “independent  avionics” 
resulted  in  a  single-function  thread  from  the  aperture  to  a 


The  versatility  of  the  digital  computer  doomed  this 
architecture  because  of  the  resulting  network  bottleneck  that 
resulted  from  its  use.  Despite  limited  memory  and  slow 
speeds  (by  today’s  standards),  the  first  models  of  digital 
computers  could  perform  several  different  data  processing 
functions  on  a  time  sharing  (i.e.,  multiplexed)  basis.  As  a 
result,  the  outputs  of  several  low  bandwidth  sensors  (e.g., 
inertial  platforms,  air  data  sensors)  were  hard-wired  to  the 
digital  computer  through  an  I/O  box  which  performed  the 
multiplexing  function  at  its  interface  to  the  computer. 
Eventually,  the  number  of  wires  became  so  excessive  that  a 
data  transfer  bottleneck  occurred,  with  the  I/O  box  being 
more  complex  and  costly  than  the  computer  itself.  The 
solution  was  to  extend  the  multiplex  boundary  from  the  I/O 
box/computer  interface  to  all  the  information  sources  and 
sinks  on  the  network  by  multiplexing  signals  over  one  wire 
media.  Computer  speeds  had  become  fast  enough  to  multiplex 
the  data  on  a  system  network  and  still  achieve  "real  time” 
processing  capabilities.  Federated  avionics  (Figure  7)  was 
ushered  in  by  time-sharing  data  over  the  physical  interconnect 
media.  This  architecture,  using  the  MIL  STD  1553 
(STANAG  3838)  multiplex  protocol  is  typical  of  the  vast 
percentage  of  military  avionics  flying  today  and  has  proven  to 
be  highly  versatile  and  useful  despite  its  1  Megabit/second 
speed  limitation. 

Although  this  architecture  has  been  labelled  as  federated,  this 
descriptor  only  applies  to  the  single  processor  control  feature 
(the  logical  part  of  the  logical,  physical  and  functional  triad 
that  makes  up  the  architecture).  In  reality,  this  so-called 
federated  system  is  an  integrated  parallel  processing  system 
which  has  a  bus-structured  interconnect  system  that 
physically  extends  over  the  aircraft.  With  the  passing  of  time, 
several  parallel  1553  busses  have  been  added  as  the  need  for 
integration  has  increased  (see  Figure  5),  with  each  bus 
performing  such  functions  as  navigation/weapon  delivery, 
electrical  power  control,  flight  control,  stores  management, 
etc.  It  is  important  to  note  the  following  attributes  of  this 
highly  successful  approach:  1)  the  network  is  a  bus-structured 
design  that  is  used  to  interconnect  data  processors,  very  low 
bandwidth  state  vector  sensors  and  control  devices.  2) 
dedicated,  highly  custom  pre-processors  and  signal 
processors  were  housed  within  a  dedicated  box  which 
outputed  low  bandwidth  data  onto  the  1553  network. 

Referring  to  Figure  7,  an  integrated  digital  system 
architecture  is  shown  next  in  the  chronology.  This 
architecture  is  typical  of  the  one  developed  by  the  US  Air 
Force  under  the  Pave  Pillar  Program  and  is  the  basis  of  the 
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approach  used  on  the  US  Air  Force’s  F-22  and  US  Army’s 
RAH-66  helicopter.  This  approach  is  characterized  by  the 
following  basic  characteristics:  1)  a  small  family  of  system- 
common  data  and  signal  processing  line-replaceable  modular 
assets  are  housed  in  physically-separated  common  racks  (see 
Figure  8),  2)  any  digital  data  or  signal  processor  asset  can  be 
accessed  at  the  common-module  level  through  an  integrated 
set  of  system-wide  networks.  Because  of  constraints  in 
technology  or  the  types  of  data  being  transmitted  over  the 
network,  a  hierarchy  of  networks  using  both  photonic  (serial, 
several  meters  distance)  and  electrical  (parallel,  backplane) 
interconnects  are  currently  used. 


Using  today’s  technologies,  networks  limitations  require  the 
mixed  use  of  both  electrical  backplanes  to  interconnect  assets 
within  say,  one  meter  and  fiber-based  networks  a  the  system 
interconnect  level.  The  following  interconnects  can  be 
affected:  high  speed,  serial,  point  to  point  digital 
sensor/display-based  information  can  be  routed  to  the 
common  integrated  processor  (CIP)  racks  by  a  photonic 
network;  serial  inter-rack  data  is  transmitted  over  a  high 
speed  data  bus;  parallel  electrical  data  is  transmitted  over  the 
electrical  backplane  of  the  CIPs  through  a  data  network 
switch  (to  handle  streaming  sensor  and  graphics  data);  a 
parallel  interface  (PI)  bus  in  the  backplane  provides  control 
and  low  bandwidth  data  transmission  between  modules.  The 
speed  of  the  point  to  point  links  is  a  function  of  the 
technology  involved.  Current  light  emitting  diode  technology 
will  allow  about  400  megabits  per  second  to  be  transmitted, 
with  laser-based  transceivers  being  available  in  about  3  years 
which  should  permit  around  2-3  Gigabits  per  second  rates  to 
be  achieved.  The  high  speed  photonic  data  bus  is  specified  to 
operate  at  50  megabits  per  second.  (Ref  2). 

Understanding  the  motivation  behind  the  shift  from  a 
federally  controlled,  bus-structured  design  to  the  integrated, 
partly  bus-controlled,  partly  point-to-point  approach  provides 
much  insight  into  the  basic  axiom  about  architecture 
evolution.  Architectures  change  to  overcome  network 
bottlenecks  caused  by  a  drive  for  increased  situation 
awareness,  cost  and  weight  savings  or  a  combination  of  these 
factors. 

The  motivation  to  move  signal  processors  inside  the  CIP  was 
partly  aimed  at  controlling  the  spiralling  cost  of  sensor- 
dedicated  signal  processors  by  using  a  small  family  of 
common  modules  that  are  system-level  assets.  Signal 
processors,  previously  part  of  the  sensor  under  the  federated 
architecture,  have  now  been  physically  removed  to  the  CIP. 
Very  high  speed  digital  sensor  data,  once  confined  to  a  local 
backplane  at  the  sensor,  must  now  be  sent  over  a  system-wide 
network.  Since  the  network  rates  of  streaming  data  from  the 
preprocessors  are  measured  in  the  hundreds  of  megabits  per 
second,  it  is  obvious  that  MIL  STD  1553  cannot  handle  the 
traffic  and  a  bus  implementation  is  totally  inappropriate  for 


the  continuous,  streaming  data  ;  a  bottleneck  has  occurred  and 
the  architecture  must  change.  A  point-to-point  distribution 
approach  between  sensor,  CIP  and  displays  is  currently  being 
used  because  the  desired  switch  network  (for  added  system- 
level  fault  tolerance)  cannot  be  built  due  to  technology 
limitations.  Another  motivating  reason  for  this  architecture  is 
that  system  weight  (and  hence  cost)  could  be  substantially 
reduced  by  having  both  data  and  signal  processors  share  the 
same  rack  and  backplanes.  All  these  characteristics  resulted  in 
supporting  the  earlier  mission  needs  cited  in  this  paper: 
improved  situation  awareness  (data  can  be  fused  more  easily 
because  it  is  accessable  across  a  common  backplane),  reduced 
maintenance  manpower,  improved  sortie  generation  and 
sustained  operation  from  austere  bases  are  simulateously 
achieved. 

The  question  to  be  asked  is  whether  this  architecture  will 
“hold  up”  over  the  next  10-20  years.  Obviously,  the  impact  of 
the  various  trends,  discussed  earlier  in  this  paper,  must  be 
assessed  to  answer  this  question. 

T _ Architectural  Enhancements  for  Digital  Systems 

In  order  to  support  the  increased  system  interconnect  speeds 
projected  for  the  future  (see  Table  2  and  Figure  3),  either  a 
few  very  high  speed  networks  will  be  needed  or  more  low- 
speed  networks  will  need  to  be  added  or  a  return  to  the 
federated  architecture  is  required  in  order  to  avoid  the  network 
bottleneck  which  will  obviously  occur  in  the  future.  The 
author  believes  that  a  return  to  the  highly-federated 
architecture  (where  processing  assets  will  communicate  over 
short  distances  across  an  electrical  backplane  and  be  loosely 
controlled  by  a  bus-structured  network)  is  not  likely  because 
the  need  to  fuse  data  before  pre-processing  and  the  desire  to 
achieve  fault  tolerance  through  reconfiguration  is  not 
optimized  using  this  approach.  One  the  other  hand,  adding 
more  low-speed  photonic  interconnects  and  continue  to  use  a 
hierarchy  of  expensive  and  bulky  optical-to-electrical, 
electrical-to-optical,  serial-parallel  and  parallel-serial 
conversion  circuitry  having  diverse  network  protocols  is  also 
not  appealing.  Figure  9  shows  the  preferred  approach,  a  high 
speed  unified  network  which  has  a  universal  protocol  that  will 
result  in  the  seamless  integration  of  processing,  sensor, 
memory  and  display  and  control  assets. 

This  approach  allows  the  use  of  the  most  appropriate  physical 
configuration  for  the  particular  application,  using  only  one 
basic  protocol  and  (if  the  technology  will  allow),  using  only 
one  type  of  physical  media  to  interconnect  processing  assets 
down  to  the  module  level.  Given  that  a  switched-network 
approach  is  preferable  (over  fixed  point-point),  the  “ideal” 
network  would  allow  the  point-point  access  of  any  module  to 
any  source  or  sink  of  information  on  the  aircraft  through  a 
high  speed  photonic  network.  Over  the  near  term,  such  an 
approach  is  deemed  unlikely  due  to  the  excessive  cost  of  the 
number  (in  excess  of  ten)  of  cross-bar  switches  required  for 
the  interconnection  fabric  for  highly  complex  designs.  Also, 
the  use  of  a  point-point  approach  to  affect  low  speed  control 


8-6 


and  address  functions  will  increase  the  complexity  of  the 
switches  and  will  increase  the  number  of  switch  nodes. 
Because  a  bus-structure  is  more  appropriate  for  these  kinds  of 
low  speed  functions,  buses  are  likely  to  remain  in  use  for  the 
foreseable  future  to  complement  the  switched  networks. 

Figure  10  shows  the  author’s  predicted  implementation  for  the 
next  architectural  evolutionary  advancement  for  the  digital 
portion  of  the  avionics  system.  The  Very  High  Speed  Optical 
(VHSON)  switched  network  allows  sensors  and  displays  to  be 
interconnected  to  the  modular  processing  assets  at  a  cluster 
level.  Clusters  are  an  assemblage  of  common  modules  that 
perform  some  processing  task  such  as  radar  signal  processing. 
This  system  network  is  projected  to  operate  at  about  2-3 
gigabits  per  second  using  graded  index  multi-mode  fiber  and  a 
laser-based  transceiver  multichip  module  located  at  each 
source  and  sink  on  this  network  A  protocol-consistent  bus 
implementation  (likely  metal  at  first)  would  interconnect 
cluster  modules  through  the  backplane.  The  features  of  this 
architecture  are  not  sufficiently  different  from  the  “integrated 
digital  architecture”  to  put  it  in  a  different  class,  although 
significant  network  enhancements  have  been  made.  Because 
of  the  modular  nature  of  the  integrated  digital  architecture, 
higher  network  speeds  can  be  obtained  by  replacing  slower 
speed  circuitry  with  laser-based  technology  when  it  becomes 
available  and  modification  of  the  backplane  and  modules  can 
also  be  done  using  a  modular  approach, 

This  next  generation  system  is  expected  to  further  evolve 
further,  as  shown  in  Figure  1 1 .  This  Figure  shows  one 
implementation  of  an  advanced  digital  system,  where  a 
photonically  switched  network  is  used  at  the  backplane.  It  is 
important  to  note  however,  that  as  system  network  speeds 
increase  because  of  photonics  technology,  the  avionics 
architect  will  have  additional  freedom  to  place  computing 
assets  at  various  locations  on  the  aircraft  with  ever-decreasing 
performance  and  weight  penalities,  while  still  accomplishing 
the  necessary  fusion  and  fault  tolerance  functions.  However, 
because  the  network  will  still  be  highly  switched-based  and 
the  computing  assets  are  not  necessarily  dedicated  to  sensors, 
any  advanced  evolutionary  steps  do  not  result  in  returning  to  a 
federated  architecture.  As  the  cost  of  photonic  components 
continue  to  be  reduced,  a  photonic  backplane  implementation 
is  expected  to  appear,  possibly  for  aircraft  entering  service  as 
early  as  2010. 

4.  Architectural  Enhancements  for  RF  Sensor  Systems 

Although  the  above-described  evolution  in  digital  systems  is 
not  expected  to  result  in  a  new  architecture,  the  application  of 
some  of  the  same  design  philosophies,  processing  and 
network  technologies,  along  with  advances  in  analog  RF 
circuits  and  A/D  converter  technology  are  expected  to  cause  a 
major  shift  in  the  way  radio  frequency  systems  will  be  built  in 
the  future.  In  the  author’s  view,  the  resulting  integrated  sensor 
system  concept,  combined  with  the  advances  described  above, 
will  permit  such  advanced  integration  capabilities  that  a  new, 


“fourth  generation”  architecture  will  be  introduced  for 
application  in  the  2010  time  frame. 

Since  over  half  of  RF  costs  are  due  to  the  “support 
electronics”  between  the  apertures  and  the  signal  processing 
assets,  new  technology  building  blocks  will  be  targeting  to 
drive  these  costs  down.  Strides  being  made  in  advanced  GaAs 
analog  circuitry  will  allow  a  small  family  of  modular 
building  blocks  to  be  built  which  will  perform  frequency 
conversion,  switching,  receiving,  signal  generation  and 
transmitter  functions  across  radar,  EW  and  CNI  functions. 
The  same  dramatic  cost,  weight,  maintenance  and  system 
availability  benefits  resulting  from  applying  VLSI  circuitry  to 
the  digital  domain  (which  made  the  integrated  digital 
architecture  possible)  will  enable  a  new  architecture  to  be 
developed  for  future  sensor  systems.  A  Wright  Laboratory 
program  called  Integrated  Sensor  System  (ISS)  is  currently 
underway  to  validate  the  practicality  of  this  concept  before 
the  turn  of  the  century,  racks.  About  20  module  types  are 
needed  for  a  full  system  implementation.  Although  not  shown 
in  Figure  12,  a  digital  photonic  network  interconnects  each 
analog  module  to  permit  “microsecond-level”  control  and 
instantiation  of  internal  switch  settings,  analog  filter  settings, 
etc.  Top  level  resource  management  software  is  resident  in 
core  processing,  which  together  with  signal  processors,  are 
located  in  a  CIP.  The  CIP  and  the  ISS  system  are  connected 
by  a  photonic,  switched  network.  Referring  to  Figure  12,  A/D 
converters  are  placed  at  the  output  of  the  receiver  modules. 
High  speed  digital  signals  (ranging  from  a  few  hundred 
megabits  per  second  to  about  10  Gigabits  per  second)  are 
routed  through  a  switched  network  to  interconnect  receiver 
modules  or  pre-processors  Figure  12  provides  a  simplified 
block  diagram  that  shows  the  modular  nature  of  the  ISS 
approach.  Although  space  does  not  permit  a  full  description  of 
this  sensor  architecture,  the  reader  may  wish  to  consult  Ref.  3 
for  an  explanation  of  its  operation. 

Note  the  close  similarity  of  the  architectural  approach  shown 
in  Figure  12  to  the  one  shown  in  Figure  10. 

The  following  observations  can  now  be  made  about  the 
features  of  this  fourth  generation  architecture  for  RF  and 
digital  processing  functions:  1)  the  same  modular  design 
approach  will  be  used  for  both  functions,  2)  the  same  types  of 
digital  switches  for  CIP  and  ISS  architectures  are  needed  for 
both  designs  and  can  be  made  to  be  identical,  3)  a  digital 
photonic  network  is  needed  to  interconnect  modules  whether 
they  are  part  of  the  ISS  complex  or  part  of  the  CIP  in  the 
future  and  they  can  be  made  to  be  identical,  4)  with  the 
increase  of  network  speeds  in  the  future,  the  placement  of 
signal  pre-processors  in  the  ISS  system  or  in  the  CIP  becomes 
the  choice  of  the  designer,  5)  because  photonics  will  allow 
the  co-habitation  of  digital  signals  and  sensitive  RF  signals  in 
a  common  backplane  without  interference,  advanced  modular 
avionics  racks  can  support  electrical  RF  and  digital  modules. 

The  fundamental  conclusion  to  be  drawn  from  these 
observations  is  that  a  new  fourth  generation  architecture  will 
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eventually  evolve  such  that  the  avionics  architect,  for  the  first 
time  in  the  history  of  avionics,  will  have  the  design  freedom  to 
physically  place  analog,  pre-processor,  signal  processor  and 
data  processor  modular  assets  at  any  location  on  the  aircraft 
depending  on  the  availability  of  space  and  the  need  to  fuse 
information.  The  primary  enabling  technology  which  has 
allowed  this  capability  is  the  advancement  in  photonic 
networks  where  system  network  speeds  are  on  the  same  scale 
as  backplane  speeds.  Figure  13  shows  the  implementation  of 
this  architecture.  The  reader  should  not  assume  that  any  of  the 
modules  shown  are  necessarily  located  close  together  or  far 
apart.  Network  bottlenecks  are  removed,  either  by  the  use  of 
high  speed  photonic  networks  at  the  system  interconnect  level 
or  by  the  placement  of  modules  close  together  across  a 
photonic  backplane.  The  author  estimates  that  this  kind  of 
architecture  could  appear  as  early  as  2010. 

5.  Future  Evolutionary  Enhancements 

Figure  13  also  shows  the  use  of  some  new  technologies  which 
are  expected  to  continue  the  evolution  of  this  architecture. 
For  example,  the  cost,  performance  and  weight  advantages 
resulting  in  dramatic  increases  in  the  speed  and  performance 
of  A/D  converters  will  allow  the  use  of  digital  CNl  and  the 
digital  boundary  of  the  intermediate  frequencies  for  both  ESM 
and  radar  receivers  will  move  one  to  two  stages  closer  to  the 
aperture.  Digital  data  rates  approaching  ten  gigabits/second 
will  be  needed  to  be  switched  between  receiver  and  pre¬ 
processors,  requiring  the  use  of  single  mode  fiber  optics. 
Further,  coax  cable  will  increasingly  be  replaced  by  analog 
single  mode  fiber  for  RF  and  for  local  oscillator  signal 
distribution.  Further,  strides  made  in  optical  heterodyning  will 
allow  the  replacement  of  costly  and  bulky  electrical  frequency 
conversion  hardware  with  highly  compact  optical 
components. 

4 _ Conclusions 


The  most  dramatic  changes  in  architecture  will  occur  in  the 
area  of  RF  support  electronics,  where  many  of  the  same 
features  of  modularity  and  resource  sharing  being  currently 
used  in  the  CIP  will  be  adopted  for  RF  systems.  Because  of 
advanced  RF  circuits,  A/D  convertors,  digital  processing  and 
networks,  the  RF  system  architecture  will  become  very  similar 
to  the  advanced  CIP  architecture.  The  merger  of  these  two 
architectures  and  the  projected  improvements  in  network 
speeds  will  eventually  allow  the  emergence  of  the  fourth 
generation  architecture  in  the  2010  time  frame. 
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The  history  of  avionics  architectures  is  strongly  controlled  by 
a  process  that  is  driven  by  the  desire  to  improve  weapon 
system  lethality  and  survivability  through  situation  awareness 
enhancements.  The  process  is  highly  evolutionary,  with  new 
sensors,  processors  and  interconnecting  networks  being 
incrementally  added  until  fundamental  network  bottlenecks 
forces  the  architecture  to  change  to  another  plateau,  where  the 
process  continues. 

The  current  integrated  digital  architecture  has  only  recently 
been  introduced  and  has  many  years  of  growth  potential 
remaining,  although  network  speed  improvements  will  be 
necessary  to  support  increased  processor  speed  requirements. 
However,  because  this  architecture  was  designed  with  ease  of 
retrofit  in  mind,  these  changes  can  be  made  relatively  easy  by 
the  use  of  high  speed  laser-based  transceivers  and  optically 
switched  network  modules  in  the  CIP. 


TABLE  1 

Data  Rate  and  Throughput  Projections  (Circa  2010) 


AoDlication 

Data  Rate  Per  Channel 

Throughout  (Include  Processing 

MBITS/SEC 

Preprocessing)  (GOPS) 

IRST 

120-180 

6-10 

ATR 

— 

2-5 

FLIR 

120-160 

3-10 

SAR/MTI 

800+ 

50+ 

EO 

300-500 

15-20 

EW 

1700-3500 

5-11 

Sensor  Fusion 

400  MIPS 

TABLE  2 


DIGITAL  AVIONICS  NETWORKS 


NF.TWORK/NAMF, 

S'l  ANDARD 

MAX  SPEED 
MBITS/SEC 

FUNCTIONAL 

USE 

AIRCRAIT 

USE 

MEDIA 

PROTOCOL 

MIL  STD  IS53B; 
STANAG  3838 

I 

SYSTEM  BUS 

MILITARY 

AIRCRAFT 

TSP* 

COMMAND/ 
RESPONSE  BUS 

MIL  STD  I773A 

1  OR  20 

SYSTEM  BUS 

TBD 

FIBER 

COMMAND/ 
RESPONSE  BUS 

ARINC  629 

2 

SYSTEM  BUS 

COMMERCIAL 

AIRCRAFT 

TSP 

COMMAND/ 
RESPONSE  BUS 

ARINC  636 
(FDDII* 

100 

SYSTEM  BUS 

BOEING  777 

FIBER 

COMMAND/ 
RESPONSE  BUS 

STANAG  3910 

1  AND  20 

SYSTEM  BUS 

RAFALE 

COAX 

TOKEN 

PASSING  BUS 

AS4(I74  (HSDB) 

50 

SYSTEM  BUS 

F-22,  RAH-66 

FIBER 

TOKEN 

PASSING  BUS 

FOTR 

400 

HIGH  SPEED 
STREAMING  SENSOR 
&  VIDEO  DATA 

F-22,RAH-66 

FIBER 

PT-PT-SERIAL 

PI  BUS  (AS  4710) 

400 

BACKPLANE  BUS 

F-22 

COPPER  TRACES 

COMMAND/ 
RESPONSE  BUS 
(PARALLEL) 

DATA  FLOW 
NETWORK  (AS  4709) 

800 

BACKPLANE 

SWITCH 

F-22 

COPPER  TRACES 

PT-PT-SWITCH 

(PARALLEL) 

TSP  -  TWISTED  SHIELDED  PAIR 


ARINC  -  AIRBORNE  RADIO  INCORPORATED 
FDDI  -  FIBER  DISTRIBUTED  DATA  INTERFACE 

HSDB  -  HIGH  SPEED  DATA  BUS 

FOTR  -  FIBER  OPTIC  TRANSMIT/RECEIVER 


TABLE  3 

Available  Avionic  Networks  (Circa  1994) 
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Bus 

^\^Protocol 

Parameter 

ARINC  429 

1773 

Dual  Speed 
1773 A 

STANAG 

3910 

ARINC  629 

ARINC  636 
(FDDI) 

Availability 

now 

now 

now 

now 

now 

now 

Optical  Receiver  cost 

$175 

$1000  (XCVR) 

$500 

$1500 

$1000 

$200 

Optical  Transmitter 
cost 

$150 

$244 

$1200 

$800 

$150 

Protocol  Device  cost 

$112 

$650 

$800 

$400 

$200 

$300 

Temperature  range 

MIL 

MIL 

MIL 

MIL 

MIL 

Designed  to 
883,  no  testing 

Data  rate 

100KB 

1  mbps 

20  mbps 

1  and 

20  mbps 

2  mbps 

100  mbps 

F.O.  Cable  Interface 

100/140 

100/140 

100/140 

100/140 

100/140 

100/140 

U.S.  Current  and 
Future  Standards 
Compatability 

yes 

yes 

yes 

no 

yes 

yes 

Manufacturer 

Honeywell 

Motorola 

Holt 

Litton 

Poly  scientific, 
SCI 

Litton 

Poly  scientific, 
SCI  (4th  Q) 

SEL, 

Alcatel 

Litton 

Polyscientific, 

Boeing 

FC  suitability 

yes 

yes 

yes 

yes 

yes 

no 

Source:  Flash  Program,  McDonnell  •  Douglas  Aircraft 
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Figure  1 

Commer  cial-Of f-The-Shelf  Data  &  Signal  Processor  Forecast 


Calendar  Year 

Figure  2 

Projected  Sizes  Of  Gate  Arrays 
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More  Functions,  Automation,  Sharing,  Testing,  Reliability,  Software  and  Cost 

Figure  3 

Avionics  Architecture  Evolution 


PACE  (EST) 
MRF 


•  F-106^ 


•  F-111F 


BLACK  BOX 
AVIONICS 


MODULAR 

AVIONICS 


SIGNAL  PROCESSING  (MOPS) 


Data  Rate  (Mbits/sec) 


1000000 


•  PAVE  PACE 


100000 


10000 


1000 


100 


10 

F-15  F-16 

1  • - =•— 

1970 


B-2 

•  ' 

B-1  _  • 

B-52  F.15E 


1980  '39° 

Year 


F-22 


Point-to-Point  & 
Multiple  Highspeed 

1553B  Data  Bus 

Buses  Photonics 


2000 


2010 


Figure  5 

Growth  of  System-Level  Network  Speed 


73  Modules  (79  Slots) 

•  400  MIPS 

•  2,350  MFLOPS 
.  3,600  MOPS 

■  15  Power  Supply  Modules 


7  Modules  (7  Slots) 

>  450  MIPS 

•  7,200  MFLOPS 

•  1  Power  Supply  Module 


Figure  6 

Processor  Technology  Impact 


Independant  Avionics 
(Circa  ig40't-1950's) 


Federated  Avionics 
(Circa  1960'8-  1970’s) 


Advanced  Integrated  Avionics 


Integrated  Avionics  (Circa  Post  2000) 

(Circa  1980‘t  -  1990‘s) 


Figure  7 

Architecture  Evolution  Configurations 


SDDN  COMMON  PROCESSORS  VDDN 


<  >  data  network  switch  parallel  electrical  interconnect 

◄ — ►  serial  optical  interconnect 


Figure  8 

Integrated  Digital  Avionics-Third  Generation  Architecture 


Eariv/Mid  1990s 


Late  1 990s,  Early  2000s 


Figure  9 

Network  Evolution 
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COMMON  PROCESSORS 


Figure  10 

Advanced  Integrated  Digital  Avionics 
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Technology  Transparency  in  Future  Modular  Avionic  Systems 


R.A.Edwards 

British  Aerospace  Defence,  Military  Aircraft  Division 
W392D  Warton  Aerodrome 
Preston 
PR41AX 
United  Kingdom 


1  SUMMARY 

Affordability  is  a  key  driver  for  future  weapon  systems,  and  it  is 
generally  accepted  that  integrated  modular  avionics  (IMA)  can 
make  a  major  contribution  to  the  reduction  of  acquisition  and 
support  costs.  However,  the  technologies  upon  which  IMA 
depends  are  evolving  rapidly,  and  there  is  a  danger  that  emerging 
IMA  standards  and  systems  under  development  will  become 
obsolete  over  timescales  which  are  short  compared  to  military 
programme  lifecycles. 

This  paper  suggests  that  steps  can  be  taken  to  mitigate  the  impact 
of  obsolescence  on  complex  avionic  systems  by  ensuring  that 
technology  transparency  is  established  as  a  key  architecture 
characteristic,  and  is  tackled  from  the  outset  in  standardization 
activities  and  in  system  design. 

The  importance  of  technology  transparency  is  a  consequence  of 
the  rate  of  technology  development  in  relation  to  the  long  system 
lifecycle  for  military  projects,  and  the  need  for  interchangeability 
and  backwards  compatibility  of  new  building  blocks  in  "old" 
systems  in  order  to  reduce  life  cycle  costs  (LCC).  Examples  of 
how  technology  transparency  can  be  achieved  are  given  for  the 
hardware,  software  and  data  networks  domains. 

Key  areas  for  long  term  "open  system"  interface  standards  which 
support  technology  transparency  are  identified,  based  on 
information  previously  released  from  the  Allied  Standard 
Avionics  Architecture  Council  (ASAAC)  standardization 
programme  (Reference  1). 

The  implications  of  system  level  issues  (safety,  security, 
qualification,  etc.)  and  the  drive  to  exploit  Commercial  Off  The 
Shelf  (COTS)  technology  are  explored,  and  the  need  to  consider 
technology  transparency  for  system  design  tools  is  established. 

The  main  conclusion  is  that,  whilst  many  regard  technology 
transparency  as  the  "Holy  Grail"  of  IMA,  practical  solutions  are 
possible  in  a  number  of  areas  and  must  be  pursued  vigorously 
through  programmes  such  as  ASAAC  if  LCC  benefits  are  to  be 
maximized. 

2  WHAT  IS  TECHNOLOGY  TRANSPARENCY? 

Technology  transparency  is  a  system  property  which  summarizes 
the  ability  of  a  particular  system  to  accommodate  two  aspects  of 
growth:  system  growth  and  technology  growth. 

System  growth  is  the  incorporation  of  new  or  enhanced  capabilities 
in  a  system  at  various  points  in  its  life,  typically  achieved  in  current 
military  aircraft  through  a  Mid-Life  Update  (MLU).  The  large 
scale  MLU  approach  has  now  fallen  out  of  favour,  with  customers 
preferring  smaller  and  more  frequent  incremental  updates  which 
spread  the  cost  more  evenly.  The  flexibility  offered  by  Integrated 
Modular  Avionics  (IMA)  allows  these  incremental  updates  to  be 
catered  for  in  the  initial  system  design,  giving  rise  to  the  term 
Pre-Planned  Product  Improvements  (P’l). 

Technology  groM’th  is  the  incorporation  of  the  latest  technology 
with  minimal  disturbance  of  the  system  in  order  to  support  system 
growth,  or  to  minimize  support  costs  which  would  otherwise  be 
incurred  in  the  maintenance  of  obsolete  technology. 

A  technology  transparent  system  should  be  able  to  incorporate 
new  requirements  and  new  technology  with  minimal  impact  on 
Life  Cycle  Costs  (LCC). 


C.Connan 

Direction  Technique  Systemes 
Dassault  Aviation 
78  Quai  Marcel  Dassault 
CEDEX  300 

92552  Saint  Cloud  CEDEX 
France 

3  IMPORTANCE  OF  TECHNOLOGY  TRANSPARENCY 
Technology  transparency  is  important  because  it  will  be  a  major 
factor  in  determining  the  LCC  of  future  avionic  systems.  Areas 
where  technology  transparency  can  help  to  reduce  LCC  include; 

-  Design  changes/upgrades 

-  Backwards  compatibility 

-  Interchangeability 

-  Exploitation  of  commercial  technology 

-  Obsolescence 

3.1  Design  Changes/Upgrades 

When  upgrading  a  system  to  incorporate  new  requirements  it  is 
generally  necessary  to  add  supplementary  hardware/software  to 
the  existing  system.  Future  IMA  systems  must  provide  a  high  level 
of  flexibility  in  the  selection  of  the  most  appropriate  current 
technology  in  order  to  satisfy  the  new  performance  requirements, 
whilst  minimizing  LCC.  The  technology  used  for  the  original 
system  design  will  not  necessarily  be  sufficient  in  terms  of 
performance. 

Design  changes  in  one  part  of  a  system  tend  to  have  an  impact  on 
other  parts  of  the  system,  particularly  as  system  complexity 
increases.  The  cost  of  dealing  with  these  "knock-on"  effects  can 
be  considerable,  especially  in  terms  of  system  requalification. 
Technology  transparency  can  help  to  limit  the  propagation  of 
design  changes  throughout  a  system. 

3.2  Backwards  Compatibility 

Backwards  compatibility  is  the  ability  to  use  new  system  elements 
in  an  old  system  to  replace  older  elements  of  lower  performance, 
with  no  adverse  effect  on  system  operation.  The  system  need  not 
necessarily  exploit  the  improved  performance  which  they  make 
available,  the  intention  may  be  to  obtain  logistics  benefits  by 
supporting  a  range  of  aircraft  types  with  a  small  set  of  common 
items.  Since  all  the  old  elements  might  not  be  replaced  by  new 
ones  at  one  point  in  time,  future  IMA  systems  must  be  able  to 
automatically  adapt  to  the  presence  of  items  of  different 
generations  in  order  to  partition  the  applications  on  the  overall 
new  system  in  the  most  appropriate  way.  Lack  of  backwards 
compatibility  would  mean  extensive  redesign  of  existing  systems 
to  incorporate  new  elements,  or  the  maintenance  of  large  stocks 
of  dedicated  spares.  Again,  one  of  the  goals  of  technology 
transparency  is  to  minimize  the  cost  of  redesign/requalification. 

The  rate  of  technology  development  produces  many  generations 
of  new  technology  over  the  lifetime  of  a  military  aircraft,  which 
could  easily  be  40  years  from  initial  design  to  disposal.  For 
example,  the  performance  of  data  processors  is  doubling  every  18 
months  at  the  moment.  In  view  of  the  pressure  to  reduce  military 
budgets,  exploitation  of  the  cheapest  current  technology  is 
becoming  vital  to  the  maintenance  of  capabilities  to  design, 
produce  and  support  new  weapon  systems.  Without  technology 
transparency  it  would  be  necessary  to  take  into  account,  starting 
with  the  initial  design,  all  future  growth  modifications  of  the 
system  and  make  the  necessary  provisions  (mass,  volume,  cooling, 
power)  with  an  assumption  of  no  technology  upgrade  possibility 
without  almost  complete  redesign  of  the  system. 

Backwards  compatibility  can  also  be  regarded  as  an  extension  in 
time  of  another  important  goal  of  (IMA) ,  interchangeability. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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3.3  Interchangeability 

Interchangeability  is  the  ability  of  modules  of  the  same  basic  type 
and  conforming  to  a  common  standard  in  terms  of  interfaces, 
behaviour  and  minimum  performance  to  be  exchanged  with  each 
other  with  no  adverse  impact  on  the  target  system(s).  Future  IMA 
systems  must  be  able  to  accept  modules  of  the  same  type  produced 
by  different  manufacturers  to  a  common  standard  but  using 
different  implementation  technologies.  As  for  backwards 
compatibility,  one  of  the  main  drivers  for  this  is  the  need  to  reduce 
the  logistics  burden.  Further  cost  benefits  may  be  realized  due  to 
decreased  dependence  on  single-source  suppliers. 

3.4  Exploitation  of  Commercial  Technology 

Most  of  the  necessary  technologies  are  driven  by  non  avionic 
industries  (and  more  particularly  by  computing  and 
communication  industries).  The  consequence  is  that  those 
industries  can  produce  much  cheaper  and  more  capable  technology 
at  any  given  time.  They  also  drive  the  high  rate  of  technology 
change.  The  avionics  industry  can  no  longer  afford  its  own  specific 
technologies  and  needs  to  exploit  those  driven  by  other  industries. 

3.5  Obsolescence 

As  the  electronics  industry  is  market  driven,  the  technologies  are 
very  quickly  obsolete  and  not  supported  for  a  very  long  time  by 
the  electronic  components  manufacturers:  around  3  years  for  data 
processors,  interface  drivers  or  memory.  The  cost  of  supporting 
obsolete  technology  is  very  high,  with  semiconductor 
manufacturers  becoming  increasingly  unwilling  to  cater  for  the 
relatively  small  military  market.  The  pace  of  obsolescence  is  still 
slower  for  other  technologies  but  will  probably  increase  during 
the  next  decade,  mainly  in  the  network  domain  with  the  arrival  of 
high  performance  protocols  and  large  bandwidth  physical  support 
such  as  fibre  optics. 

Design  and  development  tools  used  to  be  spiecific,  but  more  and 
more  generic  tools  usable  for  avionics  are  appearing  on  the  market. 
This  trend  will  increase  as  the  technologies  used  by  the  avionics 
industry  and  the  commercial  market  converge.  Tools  which  are 
designed  with  current  technologies  in  mind  will  become  obsolete 
at  a  rate  similar  to  the  electronic  component  obsolescence  rate. 

Software  technology  in  the  operating  system  and  language 
domains  is  still  evolving  at  a  lower  sfieed  than  hardware  because 
of  the  immense  investment  in  time  and  effort  needed  to  produce 
each  standard.  However,  it  is  important  to  pay  close  attention  to 
the  development  of  software  technology  because  software  costs 
have  a  large  impact  on  the  affordability  of  complex  systems. 

At  the  module  level,  packaging  and  assembly  materials  and 
processes  are  also  developing  quickly,  leading  to  shorter  lifetimes 
for  very  specialised  and  expensive  manufacturing  and  repair 
equipment.  The  primary  goal  of  technology  transparency  is  then 
to  ensure  that  when  new  technology  is  incorporated  into  a  product 
it  remains  totally  backwards  compatible  with  existing  products  of 
the  same  type  already  in  the  field.  This  approach  will  greatly  reduce 
the  logistics  burden  for  the  users,  as  well  as  allowing  the  most 
cost-effective  technology  to  be  adopted  on  a  rolling  basis. 

When  a  technology  is  changed  inside  a  system,  the  system  requires 
requalification.  In  a  rapidly  changing  commercial  environment, 
the  degree  of  requalification  necessary  must  be  minimized  in  order 
to  reduce  costs.  Technology  transparency  can  be  exploited  to 
restrict  the  scope  of  requalification  when  new  technology  is 
introduced. 

4  ACHIEVING  TECHNOLOGY  TRANSPARENCY 

The  examples  given  below  are  intended  to  demonstrate  that 
technology  transparency  can  be  incorporated  into  IMA  concepts. 
Three  areas  of  technology  are  addressed:  electrical  power  supplies, 
software  and  optical  data  transmission. 

4.1  Technology  Transparency  -  Power  Supplies 
A  good  example  of  how  technology  transparency  can  be  achieved 
in  IMA  is  provided  by  the  distribution  of  electrical  power  to  line 
replaceable  modules  (LRMs)  in  a  rack  via  a  backplane.  A  common 
method  is  to  use  a  number  of  power  conversion  modules  (PCMs) 
to  convert  the  platform  electrical  supply  voltage  to  logic  levels 
(sometimes  in  two  stages),  which  are  then  routed  along  the 
backplane  as  dedicated  rails  and  picked  up  by  the  appropriate 


LRMs  (Figure  1 ).  This  may  be  an  efficient  approach  at  a  particular 
point  in  time,  but  from  the  point  of  view  of  technology 
transparency  it  has  a  number  of  serious  weaknesses. 


PLATFORM 

SUPPLY 


Figure  1:  Conventional  Power  Distribution 


Firstly,  a  number  of  different  voltages  must  be  generated  to  cater 
for  the  different  technologies  used  by  the  full  set  of  LRMs,  e.g. 
+5W,  +15V,  +12V,  -2V,  -5.2V,  etc.  This  increases  the  complexity 
of  the  electrical  backplane,  giving  rise  to  many  dedicated 
individual  power  and  return  paths,  each  of  which  must  be  assigned 
to  a  separate  pin  in  the  common  LRM  connector.  A  number  of 
different  PCMs  may  be  required  to  cover  the  full  range  of  voltages. 


Secondly,  the  technology  development  trend  in  semiconductor 
logic  is  for  lower  voltages  in  order  to  reduce  electrical  power 
requirements  and  heat  dissipation,  with  +3.3V  replacing  -t5V  at 
the  moment  and  progressively  lower  voltages  planned  by 
manufacturers.  PCMs  dedicated  to  particular  logic  levels  can 
therefore  become  obsolete  rapidly  as  LRMs  incorporating  the 
latest  technology  are  brought  into  the  system.  Backwards 
compatibility  of  new  LRMs  in  old  systems  may  therefore  be 
difficult  to  achieve  without  expensive  large  scale  refits. 


Thirdly,  electronic  packaging  densities  are  increasing,  leading  to 
higher  LRM  electrical  power  requirements  and  heat  dissipations 
(even  though  the  trend  for  many  individual  devices  is  in  the 
opposite  direction).  Some  sources  predict  liquid  flow  through 
(LFT)  cooled  modules  with  dissipations  in  excess  of  200W,  which 
would  result  in  a  backplane/pin  current  for  a  single  LRM  of  more 
than  60A!  Even  if  LRM  electrical  power  requirements  can  be 
constrained  to  levels  which  are  compatible  with  conduction 
cooling,  the  conventional  approach  to  power  distribution  leads  to 
unacceptably  high  backplane  currents  and  voltage  drops. 


A  technology  transparent  solution  to  these  problems  is  to  distribute 
a  single  dc  voltage  on  the  backplane  and  provide  dedicated  dc  to 
dc  converters  at  the  point  of  use  on  each  LRM  (Figure  2).  The 
backplane  voltage  must  be  high  enough  to  keep  backplane  currents 
and  voltage  drops  within  acceptable  limits  for  the  anticipated  range 
of  LRM  power  consumptions.  The  two  leading  contenders  at  the 
moment  are  •f48V  and  -I-270V.  A  useful  analogy  in  the  commercial 
world  is  to  regard  the  desktop  PC  as  being  equivalent  to  an  LRM 
in  an  IMA  system.  The  PC  electrical  power  supply  interface  has 
very  good  technology  transparency,  catering  for  two  external 
supply  voltage  ranges  (100  to  125  V  ac  and  200  to  240V  ac)  via  a 
single  standard  three  pin  connector  and  a  voltage  range  selector 
switch. 
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PLATFORM 
SUPPLY  A 


PLATFORM 
SUPPLY  B 


Figure  2:  Technology  Transparent  Power  Distribution 


4.2  Technology  Transparency  -  Software 
An  example  of  how  the  achievement  of  technology  transparency 
can  be  more  challenging  is  provided  in  the  software  architecture 
(Figure  3).  The  software  operating  system  is  a  vital  component  of 
IMA  which  plays  a  central  role,  not  just  in  controlling  the  whole 
system,  but  also  in  achieving  independence  of  the  application 
software  from  the  underlying  hardware.  Hardware/software 
independence  is  a  key  IMA  property  which  helps  to  deliver 
multi-vendor  LRM  interchangeability  in  the  short  term  and 
technology  transparency  in  the  longer  term.  A  well  defined  and 
stable  Application  to  Operating  System  (APOS)  interface  is  part 
of  the  answer,  but  the  need  to  avoid  application  software  and 
opierating  system  recompilation  when  the  target  hardware  is 
changed  means  that  technology  transparency  must  also  be  taken 
into  account  in  the  definition  of  the  lower  level  Module  to 
Operating  System  (MOS)  interface  and  the  Module  Support  Layer 
(MSL). 


Figure  3:  Software  Architecture  Model 


APOS 

MOS 


The  MOS  interface  can  be  described  in  terms  of  two  components, 
functional  and  physical.  Like  the  APOS,  the  MOS  functional 
definition  consists  of  a  set  of  services  and  is  relatively 
straightforward.  The  physical  component  describes  the  processing 
hardware  configuration  details  (word  length,  instruction  set, 
registers,  etc.),  which  will  vary  from  supplier  to  supplier  and  will 
change  as  technology  advances.  A  number  of  approaches  to 
interchangeability/technology  transparency  are  possible  at  this 
level  (Reference  2),  with  the  Virtual  Binary  Interface  (VBI)  and 
the  Virtual  Object  Interface  (VOI)  being  the  leading  candidates. 


Both  VBI  and  VOI  overcome  the  problems  posed  by  differing 
implementation  configurations  and  capabilities  for  LRMs  of  the 
same  type  by  imposing  a  single  standard  physical  description  of 
the  hardware  which  defines  a  "virtual  machine".  The  application 
software  and  the  operating  system  are  compiled  to  execute  on  this 
virtual  machine,  and  the  MSL  supplied  by  the  LRM  manufacturer 
must  then  handle  translations  between  the  virtual  machine  and  the 
actual  native  hardware.  The  Virtual  Binary  Interface  carries  out 
this  translation  at  the  binary  level  as  each  instruction  executes, 
giving  binary  code  portability.  The  Virtual  Object  Interface 
incorporates  an  "install"  routine  in  the  MSL  which  is  invoked  when 
the  software  is  first  loaded,  carrying  out  the  translation  just  once 
prior  to  execution.  VOI  therefore  allows  object  code  reuse. 

Although  VBI  and  VOI  appear  to  have  the  potential  to  deliver 
interchangeability  and  technology  transparency,  more  work  needs 
to  be  done  to  establish  whether  the  p)erformance  penalties  of  these 
techniques  will  be  acceptable  in  a  practical  IMA  system.  This  is 
a  challenging  topic,  but  it  might  not  ^  necessary  to  adopt  VBIA^OI 
for  the  first  generation  of  IMA  technology  as  there  may  only  be 
one  supplier  per  LRM  type  in  a  particular  project.  An  appropriate 
technique  could  be  used  as  more  capable  technology  became 
available  and  LRM  supplier  diversity  increased.  However,  it  is 
encouraging  to  note  that  more  and  more  commercial  processors 
are  able  to  emulate  other  manufacturers’  devices  using  a  variety 
of  techniques. 

4.3  Technology  Transparency  -  Optical  Network 

The  final  example  looks  at  the  data  transmission  network,  and 

illustrates  how  difficult  it  can  be  to  guarantee  technology 

transparency. 

There  are  two  main  data  network  interface  areas.  The  higher  level 
Network  Independent  Interface  (Nil)  allows  the  software 
(applications  and  operating  system)  to  makeuse  of  communication 
services  without  knowledge  of  the  network  protocols  and 
technologies.  The  Nil  is  effectively  part  of  the  lower  level 
operating  system  interface,  the  MOS,  and  should  not  be  a  problem 
from  the  point  of  view  of  technology  transparency. 

The  lower  level  Module  Physical  Interface  (MPI)  has  electrical, 
optical,  mechanical  and  cooling  domains,  all  of  which  are  exposed 
at  the  physical  boundary  of  the  LRM.  Technology  transparent 
interfaces  for  these  domains  must  therefore  be  carefully  defined 
so  that  LRM  interchangeability,  interoperability  and  backwards 
compatibility  are  preserved  whenever  the  underlying  technology 
changes.  The  optical  interface  domain  poses  the  biggest  problems 
for  technology  transparency  in  the  MPI. 

There  seems  to  be  a  general  consensus  that  future  IMA  data 
networks  will  be  based  on  serial  optical  fibre  paths  with  individual 
channel  capacities  measured  in  gigabits  per  second.  As  data  and 
signal  processing  capabilities  are  likely  to  continue  to  grow 
rapidly,  the  challenge  for  the  data  network  physical  interface  is  to 
provide  sufficient  bandwidth  (perhaps  in  the  form  of  multiple  ports 
per  LRM)  to  fully  exploit  LRM  processing  capabilities.  The 
history  of  PC  development  shows  that  a  particular  data 
communication  technology  can  rapidly  become  a  bottleneck  in  the 
system,  drastically  limiting  overall  performance. 

Optical  data  transmission  offers  enormous  potential  for  increasing 
bandwidth  as  time  goes  on,  but  the  dilemma  at  the  moment  is  that 
there  are  numerous  permutations  of  optical  technology  options 
which  might  be  technology  transparent.  At  this  early  stage  of 
development  there  is  insufficient  information  on  future  trends  and 
risks  to  make  confident  decisions  on  which  options  to  design  into 
the  first  implementation.  Single  mode  fibre  with  laser  transmitters 
appears  to  be  the  most  technology  transparent  combination  but  is 
perceived  to  be  the  highest  risk,  especially  with  regard  to  connector 
contamination  and  vibration  performance.  Lower  risk  options  such 
as  graded  index  fibre  with  light  emitting  diode  (LED)  sources  have 
more  limited  growth  potential  but  could  probably  satisfy  the 
performance  needs  of  first  generation  IMA  systems.  The  decision 
is  further  complicated  by  the  need  to  minimize  costs,  which 
encourages  the  use  of  commercially  available  technologies  and 
devices  in  preference  to  unique  solutions. 

The  problems  in  setting  technology  transparent  standards  for  the 
optical  interface  to  LRMs  are  therefore: 
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(a)  Future  high  performance  LRMs  may  be  forced  to  adopt  new 
technology  which  is  not  backwards  compatible  with  first 
generation  low  risk  technology. 

(b)  The  technology  selected  today  may  not  be  cost  effective  in 
the  future  if  it  does  not  have  long  term  commercial  support. 

(c)  The  most  technology  transparent  options  tend  to  carry  the 
highest  risk  in  the  short  term. 

(d)  There  is  no  guarantee  that  optical  communication  will  be 
adopted  -  research  into  high  frequency  electrical  alternatives 
is  continuing. 

Fortunately,  a  considerable  amount  of  R&D  effort  is  being  put  into 
this  topic! 

5  STANDARDS 

The  previous  examples  show  that  the  key  to  achieving 
interchangeability  and  technology  transparency  is  the  creation  of 
stable  interfaces,  which  implies  a  need  for  interface  standards. 
Hardware  and  software  interfaces  must  be  very  well  defined, 
taking  into  account  the  likely  growth  in  the  requirements  of  users 
and  technology  development  so  as  to  avoid  performance 
bottlenecks  and  technological  dead  ends.  Module  behaviour 
behind  the  interfaces  must  also  be  explicitly  defined,  but  in  a  way 
which  is  independent  of  the  implementation  technology. 
Technology  dependent  factors  such  as  performance  need  to  be 
separated  out  from  interface  and  behavioural  descriptions,  for 
example  as  "slash  sheet"  supplements  to  standards.  The  definition 
of  technology  transparent  standards  for  IMA  is  challenging,  but 
is  feasible  if  the  emphasis  is  focused  on  interface  standards  rather 
than  product  standards. 

S.l  Interface  Standards 

The  key  interfaces  which  were  selected  for  standardization  in 
Phase  I  of  the  ASAAC  programme  (Reference  1)  and  used  for  the 
examples  in  section  4  are  summarized  below: 


SOFTWARE 

APOS 

Application  to  Operating  System  -  the  higher  level 
operating  system  interface  to  the  application  software 

MOS 

Module  to  Operating  System  -  the  lower  level  operating 
system  interface  to  the  hardware/firmware 

DATA  NETWORK 

Nil 

Network  Independent  Interface  -  the  higher  level 
firmware  to  operating  system  interface  (at  or  below  the 
level  of  the  MOS) 

PHYSICAL 

MPI 

Module  Physical  Interface  -  split  into: 

Electrical 

Optical 

Mechanical 

Cooling 

5.2  Open  Standards 

IMA  standards  need  to  give  the  system  integrator  and  the  system 
user  a  degree  of  supplier  independence  by  allowing  alternative 
sources  for  a  particular  building  block,  hence  the  importance  of 
interchangeability  and  technology  transparency.  This  will  permit 
more  flexible  purchasing  decisions  to  be  made  on  the  basis  of 
supplier  performance,  cost  and  schedule  factors.  Although  some 
manufacturers  may  feel  uncomfortable  about  potentially  having 
to  compete  for  ongoing  business  in  a  particular  project,  the  fact 
that  supplier  independence  encourages  supplier  competition 
should  be  seen  as  a  way  of  preventing  a  single  manufacturer  from 
totally  dominating  the  market.  From  the  point  of  view  of  the 
supplier,  standards  must  bed  designed  so  as  to  provide 
opportunities  to  incoiporate  innovations  whilst  still  remaining 
compliant  with  the  standard  interfaces.  Suppliers  need  to  be 
actively  involved  in  maintaining  the  set  of  standards  to  ensure  that 
the  interfaces  do  not  start  to  constrain  innovation  as  time  goes  on. 


A  set  of  IMA  standards  which  permits  supplier  innovation  will 
help  to  establish  the  product  differentiation  which  is  necessary  for 
a  more  open  market  to  be  successful. 

The  need  to  support  supplier  innovation,  supplier  independence, 
supplier  competition,  interoperability,  interchangeability  and 
technology  transparency  suggests  that  IMA  should  be  based  on 
open  standards.  Open  standards  should  define  an  open  generic 
architecture  in  terms  of  interfaces,  building  blocks  and  guidelines 
so  that  open  system  architectures  can  be  constructed.  The 
following  points  constitute  a  checklist  which  should  help  to 
determine  "openness": 

1 .  Information  published  &  publicly  available  -  open  access. 

2.  Sufficient  information  provided  to  allow  implementation  (not 
reliant  on  unpublished  material). 

3.  No  royalties  payable  on  use  of  the  information  -  open 
exploitation. 

4.  Not  dependent  on  proprietary  components  or  processes. 

5.  Standards  and  essential  components  not  restricted  by  export 
control  regulations. 

6.  Possible  to  create  special  to  type  items  which  satisfy  the 
standard  interfaces  and  are  interoperable  with  other  items 
which  conform  to  the  standards. 

7.  Open  to  technology  growth  and  system  growth. 

The  creation  of  open  standards  alone  is  not  enough.  It  will  be 
necessary  to  agree  how  properties  such  as  interoperability, 
interchangeability  and  backwards  compatibility  can  be  verified. 
In  the  short  term,  the  ASAAC  Phase  II  demonstralion/validation 
programme  is  intended  to  help  by  developing  this  verification 
process.  In  the  longer  term  the  establishment  of  approved  test 
houses  is  one  possible  answer,  but  project  specific 
qualification/certification  requirements  must  also  be  taken  into 
account.  The  standards  must  work  well  together  as  an  integrated 
set,  and  the  drive  to  adopt  commercial  standards  which  have  been 
originated  in  isolation  could  make  this  a  challenging  proposition. 
The  standards  also  need  to  be  maintained  as  an  integrated  set  over 
a  long  period  of  time,  probably  requiring  the  coordination  of  a 
number  of  standardization  bodies.  Writing  and  maintaining 
standards  for  IMA  is  a  large  undertaking,  but  the  payback  in  LCC 
makes  it  all  worthwhile. 

5.3  Durability  of  Standards 

Assuming  that  technology  transparent  standards  for  IMA  are 
possible,  it  must  be  recognized  that  they  will  not  last  forever.  It  is 
hard  to  state  a  definite  life  expectancy  for  IMA  standards,  but  it 
seems  reasonable  for  them  to  remain  useful  for  new  designs  which 
are  initiated  during  the  life  of  the  first  project  to  apply  them,  i.e. 
around  40  years.  The  decision  as  to  when  to  switch  to  totally  new 
standards  must  be  based  on  LCC  considerations,  principally  an 
understanding  of  when  maintenance  of  backwards  compatibility 
ceases  to  be  cost  effective.  Once  satisfactory  IMA  standards  have 
been  established,  it  is  hoped  that  it  will  be  possible  maintain  their 
relevance  by  a  process  of  evolution  rather  than  starting  again  from 
scratch  with  every  standard  at  one  point  in  the  future. 

Phase  I  of  the  ASAAC  programme  (Reference  1)  looked  at  the 
problems  of  writing  long  term  standards  and  concluded  that  it 
would  be  necessary  to  base  them  on  a  set  of  well  defined  interfaces 
and  technology-independent  behavioural  descriptions.  These 
would  have  to  be  supplemented  by  slash  sheets  covering 
technology-dependent  parameters  which  would  be  issued  to 
establish  new  minimum  acceptable  performance  levels  as  time 
went  on,  taking  care  to  maintain  backwards  compatibility.  The 
traditional  approach  to  writing  standards  usually  results  in  a 
fundamental  link  between  the  required  behaviour  and  specific 
technologies,  requiring  totally  new  standards  when  a  particular 
technology  becomes  obsolete  or  constrains  performance.  This 
point  is  well  illustrated  by  the  number  of  PC  motherboard  buses 
which  have  been  introduced  over  the  last  13  years,  e.g.  ISA,  EISA, 
MCA,  VESA  Local  Bus,  PCI,  etc.  Prospective  writers  of  long  term 
IMA  standards  therefore  need  to  look  carefully  at  existing 
standards  which  have  stood  the  test  of  time  and  establish  an 
appropriate  approach  before  rushing  into  print. 
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It  is  important  to  recognize  that  the  durability  of  interface  standards 
will  vary  at  different  levels  in  the  system,  and  that  this  will  not  be 
a  problem  if  the  set  of  standards  has  been  carefully  planned.  For 
example,  it  should  be  possible  to  define  the  high  level  Application 
to  Operating  System  (APOS)  interface  (Figure  3)  so  that  it  is  stable 
over  a  long  period  of  time.  Future  systems  will  require  large 
amounts  of  application  software,  so  stability  of  the  APOS  interface 
will  greatly  reduce  software  LCC  by  facilitating  reuse  and  software 
maintenance.  The  lower  level  Module  to  Ofterating  System  (MOS) 
interface,  however,  must  be  tuned  to  the  underlying  hardware  if  it 
is  not  to  limit  the  exploitation  of  more  capable  technology.  The 
MOS  definition  may  therefore  need  to  be  updated  every  few  years 
to  incorporate,  for  example,  new  hardware  features.  This  is  not  a 
serious  problem,  as  the  Module  Support  Layer  (MSL)  is  provided 
with  each  LRM  by  the  manufacturer.  An  ujxlated  operating  system 
can  be  used  which  has  the  new  MOS  interface  features,  comparable 
to  the  situation  with  PC  operating  system  upgrades  which  cater 
for  new  microprocessors.  The  updated  operating  system  must 
obviously  maintain  backwards  compatibility  with  existing 
application  software  via  the  APOS  interface. 

In  the  data  communication  network  it  is  the  lower  level  interface 
which  must  be  the  most  stable.  This  is  because  the  optical 
component  of  the  Module  Physical  Interface  (MPI)  is  exposed  at 
the  LRM  connector  and  must  be  preserved  in  order  to  maintain 
backwards  compatibility  of  new  LRMs  in  old  systems.  The  higher 
level  Network  Independent  Interface  (Nil),  which  lies  at  or  below 
the  MOS  interface,  is  not  so  exposed,  so  that  the  impact  of  any 
enhancements  can  be  handled  in  the  MSL  and  operating  system 
as  described  above. 

Long  term  IMA  standards  must  also  be  written  to  cater  for  supplier 
innovation,  i.e.  the  freedom  for  building  block  manufacturers  to 
incorporate  novel  approaches,  methods,  processes,  materials, 
devices  and  technologies  in  order  to  improve  performance  and 
reduce  costs.  The  capability  to  allow  supplier  innovation  whilst 
maintaining  interchangeability  and  technology  transparency  is  an 
important  characteristic  of  true  Integrated  Modular  Avionics. 

6  SYSTEM  LEVEL  ISSUES 

IMA  has  two  major  objectives: 

-  modularity,  which  means  that  there  is  a  set  of  standard  elements 
from  which  to  consti'uct  each  specific  system 

-  the  simplification  of  functional  and  physical  integration  in 
complex  systems 

Functional  integration  is  the  close  linkage  of  functions  which 
might  have  been  segregated  in  the  past,  e.g.  flight  control  and 
poweiplant  control,  radio  frequency /electo-optical  (RF/EO) 
sensor  fusion,  etc.  Physical  integration  is  the  sharing  of  common 
resources,  e.g.  racks,  modules,  power  supplies,  data  networks,  etc. 
IMA  does  not  define  how  the  elements  are  integrated  because  the 
rules  used  to  build  a  system  are  different  from  one  system  to 
another.  The  requirements  arc  likely  to  be  different  in  terms  of 
mission  and  operational  performance,  safety  and  security,  the 
scope  of  mission  functionality,  cost  constraints,  etc.  Each  system 
is  a  new  compromise  between  all  these  different  aspects,  leading 
to  different  integration  rules. 

The  goal  is  to  ensure  the  portability  of  core  elements  with  minimum 
redesign,  development,  requalification  when  the  technology 
changes  (between  different  systems  or  inside  the  same  system). 
Different  levels  of  portability  can  be  considered  (for  example  : 
sjaecification  level,  source  code,  compiled  code)  depending  on 
what  changes  in  the  technology.  A  universal  rule  cannot  be  given 
for  portability. 

To  ensure  the  portability  of  the  core  elements  between  systems, 
interface  standards  are  necessary  to  clearly  identify  those 
elements.  However,  each  element  cannot  take  into  account  the  sum 
of  all  possible  rules  and  constraints  dictated  by  each  specific 
system  integration.  This  has  always  been  true  in  the  past  and  the 
efficient  solution  has  generally  been  to  take  care  of  the  system 
issues  at  each  specific  application  level.  For  example,  comparison 
between  two  or  more  channels  is  a  consolidation  method  which 
has  been  used  extensively  in  order  to  satisfy  safety  requirements. 
At  the  individual  channel  level  the  safety  requirements  may  have 
no  additional  impact  as  far  as  the  components  are  concerned,  it  is 


the  addition  of  consolidation  which  is  specific.  The  safety  aspects 
are  taken  care  of  at  the  application  level,  not  by  the  use  of  particular 
technologies. 


When  the  technology  is  relatively  simple  it  might  be  possible  to 
address  such  problems  at  quite  a  low  level,  down  to  the  component 
level.  For  example,  some  safety  criticality  aspects  of  systems  can 
be  taken  into  account  at  the  transistor  level  at  one  stage  of 
technology  evolution.  When  technology  complexity  increases,  it 
becomes  more  and  more  difficult  to  take  the  system  issues  into 
account  at  such  a  low  level,  and  a  component  by  itself  might  be 
as  complex  as  a  complete  system  some  years  before.  Continuing 
the  previous  example,  it  does  not  seem  reasonable  to  take  into 
account  all  the  safety  aspects  at  the  transistor  level  when  using 
complex  microprocessors  containing  millions  of  transistors.  This 
hardware  complexity  is  of  the  same  level  of  complexity  as  the 
software  of  an  operating  system.  The  capability  to  control  the 
implementation  inside  these  types  of  complex  components  is  no 
longer  practical  for  avionic  developers. 


When  technology  changes  at  a  rapid  rate  without  any  possibility 
of  controlling  the  details  at  the  interfaces  it  becomes  more  and 
more  important  to  take  care  of  the  system  issues  at  as  high  a  level 
as  possible.  The  integration  rules  being  different  from  one  system 
to  another,  the  only  possible  level  is  the  application  level  to  ensure 
that  the  result  will  be  robust  at  the  overall  system  level.  Military 
avionics  now  takes  its  place  with  nuclear  power  generation, 
industrial  robotics,  and  the  automotive  industries  in  the  need  for 
real  time  performance  and  high  integrity  levels  where  protection 
of  personnel  and  property  is  involved.  By  analogy  with  what  can 
be  done  in  other  domains  than  avionics,  it  should  be  possible  to 
handle  the  safety  and  the  security  aspects  by  using  encoding, 
encapsulation  and  keying  techniques.  Keying  means  associating 
a  code  with  something  in  order  to  give  it  access  to  an  area,  much 
as  we  use  a  key  to  open  a  door  lock  or  enter  a  numeric  code  to  gain 
access  to  a  restricted  zone  in  a  building.  These  techniques  have 
been  developed  in  order  to  protect  a  system  or  its  components  from 
being  disturbed  by  external  influences  or  unauthorized  use  of 
facilities  or  information  (e.g.  encoding  satellite  communication 
for  acceptable  signal  to  noise  ratio,  4-digit  code  numbers  for 
cash-card  withdrawals  from  bank  machines,  sending  back 
information  for  verification). 


These  techniques  are  already  being  used  inside  systems  to  address 
some  security  aspects.  Their  use  could  be  increased  to  encapsulate 
each  element  of  a  system,  to  control  propagation  of  data  inside  a 
system,  to  protect  data  in  restricted  zones  of  a  system  (memory 
areas  for  instance),  and  to  create  firewalls  between  different  areas 
of  a  system.  The  use  of  encoding,  encapsulation  and  keying 
techniques  in  an  avionic  system  is  starting  to  become  possible 
because  of  the  rapid  improvement  of  the  computation  and 
communication  capabilities  of  emerging  technologies.  Up  to  now, 
optimization  has  always  been  necessary  because  of  the  low 
capabilities  of  technology  compared  with  functional  needs.  Extra 
overhead  was  not  affordable.  However,  emerging  technology 
offers  plentiful  computation  power,  transmission  bandwidth,  etc. 
and  could  absorb  the  overhead  whilst  remaining  affordable  in 
terms  of  volume,  mass  and  cost.  Encoding,  encapsulation  and 
keying  techniques  can  be  extrapolated  to  safety  and  security  in 
general  in  conjunction  with  the  overal  1  fault  detection  and  isolation 
techniques. 


The  application  of  techniques  which  support  technology 
transparency  will  require  new  methods  for  the  design  and 
development  of  systems.  It  will  also  require  the  re-examination  of 
system  qualification  and  certification  procedures.  The 
applications,  and  more  particularly  the  system  management 
applications  will  need  to  take  into  account  the  implementation  of 
encoding,  keying  and  other  techniques  from  the  very  beginning. 
The  codes  and  keys  will  have  to  be  adaptable  to  each  specific 
system  implementation. 
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7  COTS 

In  order  to  better  control  the  cost  of  the  systems,  the  end  users  are 
more  and  more  asking  for  Commercial  of  the  Shelf  (COTS) 
technology.  The  market  drives  COTS  standards  and  components 
to  deliver  performance  and  a  quick  return  on  investment; 
technology  transparency  is  not  an  objective. 

The  military  niche  market  has  been  using  COTS  technology  for 
many  years,  but  always  with  appropriate  ruggedization  to  meet  the 
demanding  military  physical  and  operational  environment.  Some 
examples  include  the  large  range  of  electronic  parts,  e.g. 
processors,  memory,  ASICS,  etc.,  which  use  commercial 
semiconductor  die,  and  at  the  appropriate  production  stage  are 
routed  down  a  ceramic  packaging  line  instead  of  plastic,  with 
appropriate  military  Quality  Assurance  (QA)  controls  applied. 
Other  examples  are  the  ruggedization  of  flat  panel  displays  for 
cockpits  and  fibre  optic  technology  from  the  telecommunication 
industry  for  installation  and  use  in  military  aircraft  systems. 
Looking  ahead,  there  is  no  serious  alternative  to  meeting  military 
avionics  mission  requirements  other  than  using  components  which 
have  been  developed  for  the  commercial  market.  The  competitive 
commercial  market  forces  make  for  continual  advances  in 
computing  and  I/O  and  graphics  performance,  and  good  parts  gain 
world-wide  usage.  The  use  of  ruggedized  COTS  parts  under 
controlled  conditions  will  therefore  continue  to  be  the  nonn  within 
the  military  avionics  industry. 

The  trend  is  now  towards  applying  even  more  COTS  technology 
in  the  defence  industry,  and  the  requirements  remain  just  as  strong 
for  ensuring  that  each  type  of  COTS  technology,  which  includes 
software  products,  can  be  sufficiently  ruggedized  for  military 
usage.  Most  aerospace  companies  have  past  experience  of 
apparently  cheap  COTS  technology  failing  to  meet  qualification 
requirements  at  a  crucial  stage  in  the  programme. 

The  most  important  challenges  of  using  COTS  are: 

1  Ensure  the  parts  meet  the  environmental  requirements  (i.e.  both 
the  physical  environment  and  the  software  engineering 
environment  as  appropriate)  and  make  sure  that  the 
requirements  are  not  over  specified. 

2  Ensure  the  selected  parts  have  a  reasonable  lifetime  expectation, 
bearing  in  mind  military  equipment  lifetimes  are  of  the  order  of 
25+  years  whereas  commercial  parts  lifetimes  are  typically  5 
years  and  tend  to  he  getting  shorter  as  technology  innovation 
accelerates.  Understand  how  obsolescence  will  be  handled. 

3  Be  very  careful  when  using  COTS  software,  its  documentation 
and  associated  licensing,  since  it  is  difficult  to  maintain  a 
militai'y  product  with  COTS  software  embedded. 

4  The  unique  combination  of  constraints  and  requirements  which 
militaty  aircraft  must  satisfy  dictate  that  the  level  of  COTS  usage 
will  be  within  modules,  not  the  modules  themselves. 

Point  2  is  typically  a  technology  transparency  problem  where 
techniques  as  described  in  the  previous  paragraphs  have  to  be  used. 

Forpoint  1  new  compromises  will  need  to  be  studied  when  building 
a  new  platform  or  the  installation  of  a  new  system  inside  a  platform. 
The  two  main  reliability  drivers  for  electronics  compionents  are 
temperature  and  vibration. 

For  cooling,  new  implementations  are  being  considered  including 
liquid  cooling  to  improve  the  performance  of  the  environmental 
control  systems.  The  compromise  is  between  system  reliability, 
additional  mass,  volume  and  complexity  of  platform,  LCC.  In  fact 
the  overall  environmental  control  system  needs  to  be  redesigned 
with  new  criteria  ;  for  example  the  COTS  range  of  temperature  is 
much  smaller  than  the  military  aircraft  environment  range  of 
temperature  at  high  temperatures,  but  also  at  low  temperatures. 

For  vibration,  active  reduction  (active  anti-vibration  mounting)  is 
being  considered. 

In  all  cases,  the  overall  environment  of  the  electronics  inside 
military  aircraft  will  have  to  be  improved. 

There  are  several  ways  to  consider  the  level  of  COTS  inside  a 
module: 


-  Today  it  is  considered  at  the  component  level.  Ruggedization 
is  done  at  this  level,  by  using  ceramic  casing  instead  of  plastic, 
for  example. 

-  When  complexity  increases,  it  is  necessary  to  handle  the 
problem  at  a  higher  level.  It  is  not  pwssible  to  have  a  complete 
COTS  module  because  it  will  not  te  compliant  with  the  single 
standard  interface.  However,  it  might  be  possible  to  handle  it  at 
the  next  lower  level  which  is  the  board  level.  For  example,  if  a 
processing  board  is  a  COTS  item,  then  a  module  can  contain  in 
addition  another  board  for  conversion  to  standard  power  levels 
and  to  standard  networks.  The  two  boards  can  be  encapsulated 
in  a  single  packaging  with  standard  connectors.  The  packaging 
by  itself  will  be  the  EMC  and  physical  handling  protection  of 
the  COTS  electronics.  The  physical  encapsulation  technique 
gives: 

-  a  standard  physical  interface 

-  protection  from  the  environment  (which  is  improved 
compared  to  the  existing  environment) 

-  minimum  design  and  development  for  the  adaptation  between 
COTS  and  standard  interfaces.  For  example,  if  a  COTS 
electronic  board  can  be  used  inside  a  standard  LRM  with  an 
additional  internal  interface  inside  this  LRM  between  the 
COTS  board  and  the  standard  LRM  power  supply  and 
network  interfaces,  then  when  the  COTS  board  technology 
changes  the  only  redesign  necessary  should  be  for  the  internal 
interface.  This  should  constitute  a  very  small  part  of  the  LRM. 

Module  format  will  have  to  be  adapted  to  these  techniques  and  be 
able  to  incorporate  commercial  board  formats.  The  trend  will  not 
be  to  integrate  as  much  electronics  as  possible  on  smaller  formats, 
as  has  been  the  case  in  the  recent  past  (e.g. :  SEM  E  format). 

8  SYSTEM  DESIGN  TOOLS 

So  far,  technology  transparency  has  been  considered  in  relation  to 
systems  and  system  building  blocks,  but  it  is  also  important  for 
the  tools  which  are  used  in  the  system  design  process. 

The  initial  dilemma  is  whether  to  develop  proprietary  design  tools 
or  use  what  is  commercially  available.  Proprietary  tools  have  the 
advantage  that  they  can  be  made  entirely  compatible  with  the 
originator’s  system  design  process.  However,  the  cost  of 
developing  and  supporting  an  integrated  toolset  over  the  full 
lifecycle  of  a  military  project  can  be  enormous. 

The  market  for  commercial  tools  is  developing  rapidly,  leading  to 
more  and  more  products  and  suppliers.  Although  market  forces 
should  help  to  keep  the  acquisition  and  support  costs  for 
commercial  tools  within  acceptable  limits,  it  is  difficult  to  maintain 
an  integrated  toolset  which  covers  the  full  lifecycle.  Examples  of 
the  problems  posed  by  the  adoption  of  commercial  tools  include: 

-  Difficulty  in  interfacing  tools  from  different  suppliers  due  to 
lack  of  standardization,  resulting  in  custom  solutions  for  data 
interchange.  The  trend  towards  multi-company  integrated  teams 
adds  a  new  dimension  to  this  problem. 

-  Dependency  on  single-source  suppliers,  who  may  go  out  of 
business  or  discontinue  support  for  a  particular  tool. 

-  The  need  for  tools  to  support  project  datasets  with  a  very  long 
lifetime. 

-  Rapid  development  of  the  computing  technology  on  which  the 
tools  run,  leading  to  obsolescence. 

There  are  clear  similarities  between  these  four  problem  areas  and 
factors  which  are  imptortant  for  systems  and  system  building 
blocks,  i.e.: 

-  Interoperability 

-  Interchangeability 

-  Backwards  compatibility 

-  Technology  transpatcncy 


9-7 


It  should  therefore  be  possible  to  tackle  these  toolset  problems 
using  the  techniques  which  are  being  applied  in  IMA.  Open 
standards  for  tools  are  required  to  define  the  interfaces  which  allow 
tool  behaviour  to  be  encapsulated  and  described  independently 
fiom  the  implementation  technology. 

9  CONCLUSIONS 

-  Obsolescence  is  a  major  problem,  therefore  technology 
transparency  must  be  addressed  at  the  requirements  stage. 

-  IMA  standards  are  required  in  order  to  ensure  that  technology 
transparency  is  embodied  in  IMA  products.  IMA  requires  open 
standards  which  are  endorsed  and  actively  supported  by 
industry  and  governments,  allowing  long  term  open  systems  to 
be  implemented  based  on  OTS  (Off  The  Shelf)  building  blocks. 

-  Technology  transparency  is  important  for  system  design  tools 
as  well  as  system  products,  and  can  be  tackled  using  the  same 
techniques. 

-  Technology  transparency  leads  to  inefficiency,  but  we  are  at  the 
crossover  point  NOW  with  an  increasing  abundance  of 
resources  in  processing  and  memory.  The  networks  area  is  a 
little  further  behind  in  terms  of  bandwidth  and  latencies,  but  is 
catching  up.  (See  Figure  4.).  Effectiveness  is  more  important 
than  efficiency. 


Figure  4:  Technology  Transparency  Crossover  Point 


-  Technology  transparency  is  possible,  but  the  rapid  rate  of 
technology  development  means  that  it  is  difficult  to  give 
guarantees. 


-  The  holy  grail  of  technology  transparency  is  achievable,  but  the 
market  needs  to  be  lead  in  the  right  direction  by  standardization 
programmes  such  as  ASAAC. 
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1.  SUMMARY 

This  paper  reports  on  the  refinement,  demonstration  and 
validation  of  a  number  of  key  concepts  for  Integrated 
Modular  Avionics  (MA),  as  performed  under  the  IMA 
Demonstrator  programme.  For  the  communication  network, 
software  architecture,  and  fault  management  areas,  selected 
aspects  of  the  concepts  were  refined,  and  implemented  on  a 
demonstration  platform.  This  platform,  termed  the  MA 
Demonstrator,  is  a  tool  for  investigating  and  evaluating  MA 
issues,  and  has  been  constructed  largely  from  commercial  off- 
the-shelf  components.  In  the  IMA  Demonstrator,  the 
communication  network  is  implemented  by  a  functional 
prototype  of  the  Matrix  Switched  Network.  The  software 
architecture  of  the  MA  Demonstrator  includes  functional 
prototypes  of  the  communication  system  and  the  fault 
management  system.  The  MA  Demonstrator  and  its 
functional  prototypes  have  been  used  to  validate  the  relevant 
MA  Concepts. 

2.  INTRODUCTION 

2.1.  Integrated  Modular  Avionics  Concepts 

Integrated  Modular  Avionics  (MA)  systems  are  recognised 
as  providing  an  answer  to  the  requirements  and  constraints  of 
modem  military  aircraft.  According  to  the  IMA  concept,  a 
system  implementation  is  built  up  from  hardware  modules 
and  software  components  with  standardised  interfaces, 
according  to  a  set  of  guidelines.  In  comparison  with  the 
previous  generation  of  federated  avionic  architectures,  the 
benefits  provided  by  MA  systems  will  include  improved 
fault-tolerant  operation,  leading  to  improved  operational  and 
mission  performance,  as  well  as  a  greater  openness  to  growth 
and  innovation,  and  a  reduction  of  life  cycle  costs. 

IMA  concepts  may  be  broken  down  into  the  following  areas: 

•  Software  Architecture 

•  Communication  Network 

•  Fault  Management 

•  Common  Functional  Modules 

•  Packaging. 

2.2.  Areas  of  Investigation 

From  the  key  areas  mentioned  above,  the  first  three  have 
been  selected  for  investigation  under  the  IMA  Demonstrator 
activities  reported  upon  in  this  paper.  While  all  of  the  areas 
are  inter-dependent,  the  Software  Architecture, 
Communication  Network  and  Fault  Management  concepts  are 
particularly  closely  related,  and  are  suited  to  investigation 
largely  independently  of  the  development  of  dedicated 
hardware.  National  and  international  programmes,  including 
in  particular  ASAAC  Phase  I  (Ref  1 )  and  EUCLID  /  CEPA  4 
/  RTP  4.1  (Ref  2)  provided  the  basis  for  the  IMA  concepts  to 


be  investigated.  The  MA  Demonstrator  programme  is 
performed  in  co-operation  with  a  number  of  German  avionics 
and  aircraft  companies. 

The  IMA  Network  Concept 

The  overall  IMA  network  concept  provides  for 
communication  between  the  modules  and  other  equipment  of 
the  MA  system,  and  requires  the  specification  of  a  Network 
Independent  Interface  (MI)  and  a  Network  Protocol  Stack,  as 
shown  in  Fig.  1.  The  Nil  ensures  that  the  implementation  of 
the  network  is  decoupled  from  that  of  the  operating  system 
(shown  as  the  network  user).  The  specification  of  a  protocol 
stack  based  on  a  defined  model  ensures  that  modules  are  able 
to  communicate  with  one  another.  The  circuit-switched 
Matrix  Switched  Network  (MSN)  is  proposed  for  the  relevant 
protocol  layers. 


Fig.  1:  Communication  Network  Model 

The  IMA  Software  Architecture  Concept 
The  two  main  components  of  the  software  architecture 
concept  are  the  use  of  two  well-defined  interfaces  and  the 
Blueprint  Concept,  as  shown  in  Fig.  2.  The  two  interfaces 
defined  are  the  Application  to  Operating  System  interface 
(APOS)  and  the  Module  Support  Layer  to  Operating  System 
interface  (MOS).  Blueprints  provide  a  logical  description  of 
the  system  and  define  its  mapping  onto  the  system  resources. 
Together,  the  defined  interfaces  and  the  blueprints  support 
the  independence  of  the  software  from  the  hardware, 
providing  for  software  re-usability  and  for  the  development  of 
hardware  and  software  to  accommodate  system  growth. 


Fig.  2:  Software  Architecture  Layer  Concept 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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The  IMA  Fault  Management  Concept 

A  fail-operational  concept  ensures  that  on  the  occurrence  of  a 
failure  the  system  performs  real-time  reconfiguration,  if 
necessary,  to  allow  the  function  suffering  the  failure  to 
continue  to  be  performed.  A  wide  variety  of  reconfiguration 
mechanisms  might  be  used,  including,  for  instance,  hot  stand¬ 
by  components  with  full  functionality,  and  cold  stand-by 
components  with  degraded  functionality.  On  the  detection  of 
failures  by  the  health  monitoring  services  of  the  operating 
system,  a  system  application  refers  to  the  reconfiguration 
strategy  stored  in  the  blueprints  in  order  to  reconfigure  the 
system. 

Concept  Refinement 

Selected  aspects  of  the  three  key  concept  areas  under 
investigation  have  been  refined  to  a  stage  at  which  they  may 
be  demonstrated  and  validated  on  the  IMA  Demonstrator. 

For  the  communication  network,  the  concept  for  the 
implementation  of  the  network  lower  layers  was  refined. 
Simulation  and  modelling  of  a  number  of  alternative 
networks  was  performed,  and  the  selection  of  the  MSN  as  the 
preferred  candidate  confirmed.  The  MSN  concept  was  then 
developed  further,  and  the  requirements  for  the 
accompanying  higher-level  protocol  investigated. 

Under  the  software  architecture,  concept  refinement 
addressed  the  communication  system,  which  supports  all 
forms  of  communication  within  the  IMA  concept,  and  the 
fault  management  system.  The  Blueprint  Concept  was 
developed  to  provide  the  support  required  by  the 
communication  and  fault  management  systems. 

Comparison  with  other  Models 

The  IMA  concept  models  show  many  similarities  with  other 
contemporary  open  system  architecture  models.  Figs.  3  and  4 
attempt  to  show  the  relationship  between  the  IMA 
communication  network  and  software  architecture  concepts 
and  the  following  models: 

•  IEEE  POSIX  Open  Systems  Environment  (OSE) 
standards  (Ref  3) 

•  SAE  Generic  Open  Architecture  (GOA)  framework 
(Ref  4) 

•  ISO  Open  System  Interconnect  (OSI)  Model  (Ref  5) 

•  French  MoD  Reference  Model,  GAM-T-103  (Ref  6). 

In  comparison  with  the  other  generic  models,  the  IMA 
concept  includes  some  special  features  for  the  real-time 
avionics  application,  such  as  the  Blueprint  Concept  in  the 
software  architecture  concept,  and  the  Management  and  Time 
Management  services  of  the  communication  network  concept. 
Further  discussion  of  the  comparison  of  the  models  is 
included  in  Ref  7.  Fig.  3  shows  the  relationship  between  the 
communication  models. 


ISO/OSl  Model  Network  Concept 


Fig.  3:  Communication  Models 


The  structure  of  the  IMA  communication  network  may  be 
mapped  onto  the  four  lower  layer  of  the  ISO/OSI  reference 
model  as  shown,  and  also  corresponds  directly  to  that  of  the 
GAM-T-103  standard. 


Fig.  4  shows  the  relationship  between  the  software  models. 


POSIX  OSE  Reference  IMA  Software  GOA  Framework 


Model  Architecture  Concept 

Fig.  4:  Software  Architecture  Concepts 
2.3.  The  IMA  Demonstrator 

The  IMA  Demonstrator  is  a  system  for  the  development, 
demonstration  and  validation  of  IMA  concepts.  In  its  initial 
form,  as  described  in  this  paper,  it  is  being  used  for  the 
demonstration  and  validation  of  the  concepts  addressed  in  the 
previous  section,  for  which  functional  prototypes  of  the 
relevant  components  of  the  communication  network,  software 
architecture,  and  fault  management  system  have  been 
constructed,  hi  order  to  concentrate  efforts  on  the 
demonstration  of  the  particular  concepts  of  interest,  these 
have  been  implemented,  as  far  as  possible,  on  the  basis  of 
standard  commercial  hardware  and  software.  Following  the 
development  of  functional  prototype  components  and  their 
integration  into  the  BVLA  Demonstrator  system,  an  evaluation 
is  being  performed,  which  is  to  be  concluded  with  the 
demonstration  of  a  functional  chain  for  a  representative 
avionics  application. 

The  IMA  Demonstrator  is  designed  to  provide  for  growth  in 
its  functionality  and  the  substitution  of  more  mature 
components  as  these  become  available,  in  order  to  provide 
continuing  support  for  the  development  and  evaluation  of  the 
IMA  concepts. 

The  IMA  Demonstrator  architecture  is  shown  in  Fig.  5. 


Test  Interface 


Fig.  5:  IMA  Demonstrator  Architecture 

The  components  of  the  IMA  Demonstrator  may  be  divided 
into  two  categories.  The  Demonstration  Components 
implement  the  concepts  to  be  demonstrated,  and  are  shown  in 
Fig.  5  within  the  broken  box.  The  second  category  is  the 
Demonstration  Support  Components,  on  which  the  software 
is  developed,  and  which  provide  control  and  analysis 
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facilities  for  the  demonstration.  Most  components  consist  of 
both  software  and  hardware. 

The  essential  hardware  Demonstration  Components  are 
shown  in  more  detail  in  Fig.  6. 


LCE  Link  Control  Element  CMI  Control  and  Message  Interface 

DPM  Data  Processing  Module  DTI  Data  Transmission  Interface 

SBC  Single  Board  Computer  FDDI  Fibre  Distributed  Data  Interface 

NIL)  Network  Interface  Unit 

Fig,  6:  Hardware  Demonstration  Components 

•  Data  Processing  Modules  (DPMs) 

The  DPM  functional  prototypes  are  implemented  as  VME 
racks  holding  one  or  more  commercial  PowerPCs, 
together  with  a  Network  Interface  Unit  (NIU),  which 
provides  the  interface  to  the  communication  network,  and 
which  also  consists  of  off-the-shelf  hardware. 

•  Link  Control  Element  (LCE) 

The  LCE  functional  prototype  performs  the  role  of 
switching  in  the  Matrix  Switched  Network  (MSN) 
implementation  of  the  communication  network.  The  LCE 
is  also  implemented  as  a  VME  rack,  holding  a  custom 
electrical  switch  matrix  board,  a  commercial  PowerPC 
single  board  computer,  and  other  off-the-shelf  interface 
components, 

•  DGM  (Digital  Graphics  Module) 

Following  the  evaluation  of  an  initial  IMA  Demonstrator 
configuration  as  shown  in  Fig.  6,  a  DGM  functional 
prototype  will  be  added  to  the  system  by  integration  into 
the  backplane  of  a  dedicated  DPM,  in  order  to  evaluate  a 
representative  avionic  functional  application. 

The  Demonstration  Support  Components  support  the 
development  of  software  components,  software  loading, 
demonstration  control  and  monitoring,  and  test  evaluation. 
They  are  based  largely  on  standard  commercial  products,  and 
comprise  the  following: 

•  Workstations 

These  are  standard  Sun  Sparc  workstations,  and  act  as 
hosts  for  the  Apex  Ada  development  environment. 

•  Analyser  Monitor  Test  (AMT)  System 

The  AMT  provides  analysis,  monitoring  and  test  facilities 
for  the  system,  and  is  comprised  largely  of  specially 
developed  components,  due  to  the  specific  features  of  the 
IMA  Demonstrator. 

•  Aircraft  Simulation  Environment 

The  aircraft  simulation  environment  is  added  to  the  IMA 
Demonstrator  for  the  functional  demonstration  to  be 
performed  with  the  DGM,  in  order  to  provide  for  dynamic 
system  evaluation  under  operational  conditions. 

The  IMA  Demonstrator  components  are  intercoimected  by  the 
test  interface,  which  is  implemented  as  an  Ethernet  network. 


and  provides  for  data  transfer  for  demonstration  setup, 
control  and  analysis. 

3.  CONCEPT  DEMONSTRATION 

3.1.  Communication  Network  Concept 

3. 1.1.  Requirements 

In  comparison  with  previous  generations  of  system 
architecture.  Integrated  Modular  Avionics  systems  will 
impose  considerably  higher  data  transfer  requirements.  These 
requirements,  for  communication  between  modules  and  with 
other  equipment,  within  and  between  racks,  are  to  be  fulfilled 
by  the  communication  network. 

A  number  of  requirements  on  the  communication  network 
derive  from  the  overall  IMA  aims  and  concepts.  The  splitting 
of  processing  functions  which  were  previously  contained 
within  single  equipments  and  the  accompanying  earlier 
digitisation  of  sensor  data  give  rise  to  a  considerably  greater 
total  data  transfer  volume,  with  higher  data  rates  per 
connection.  In  addition,  the  system  requirement  for  fault- 
tolerance  demands  that  the  network  supports  a  high  level  of 
mobility  of  software  functions  within  the  system  architecture. 
The  overall  IMA  aim  of  module  interchangeability  leads 
directly  to  the  requirement  that  the  communication  system 
provides  standardised  interfaces  and  operation.  The 
communication  network  must,  like  the  rest  of  the  IMA 
system,  provide  technology  transparency,  and  must  provide 
for  the  application  of  commercial  off-the-shelf  (COTS) 
technology.  The  network  should  also  be  scalable,  to  provide 
for  varied  applications,  and  should  provide  for  growth  within 
a  particular  application.  Finally,  a  universal  solution  for  all 
network  communication  requirements  is  desired,  in  order  to 
avoid  the  proliferation  of  different  hardware  and  software. 

The  current  performance  requirements  are  derived  from  the 
anticipated  data  transfer  requirements  of  the  first  IMA 
applications:  growth  capacity  should  enable  the 

communication  network  to  meet  the  more  demanding 
requirements  which  will  subsequently  arise  for  later 
applications.  While  the  requirements  of  the  various  data 
transfers  within  the  system  are  very  wide  ranging,  an  attempt 
is  made  here  to  summarise  the  driving  requirements. 

A  maximum  of  256  network  ports  is  required.  The  required 
maximum  data  transfer  rate  is  2  Gbit/sec,  in  order  to 
accommodate  digitised  sensor  data  and  uncompressed  high 
definition  video.  The  maximum  time  to  establish  a  physical 
connection  between  a  source  and  sink,  which  is  referred  to  as 
the  linking  time,  is  lOps.  The  maximum  data  latency 
requirement  is  generally  lOOps,  but  only  Ips  in  the  case  of 
some  sensor  data.  In  order  to  support  the  fault-tolerance  of 
the  overall  system,  the  communication  network  is  therefore 
required  to  provide  fault-tolerant  operation  itself. 

A  number  of  available  and  developing  network  technologies 
have  been  investigated  as  possible  solutions  to  these 
requirements,  including  the  Asynchronous  Transfer  Mode 
network,  ATM,  the  Scalable  Coherent  Interface,  SCI,  and 
Fibre  Channel.  As  none  of  these  was  considered  likely  to  be 
able  to  offer  a  very  well  optimised  solution  to  the  IMA 
requirements  in  the  relevant  timescales,  a  solution  was 
sought  which,  while  making  use  of  COTS  and  other  available 
technology,  was  more  suited  to  fulfilling  the  IMA 
requirements. 

3.1.2.  The  Matrix  Switched  Network 

The  concept  developed  in  response  to  these  new  demands  is 
that  of  the  Matrix  Switched  Network  (MSN).  The  MSN 
comprises  a  high  speed  circuit-switched  Data  Transfer 
Network  (DTN)  component,  complemented  by  a  Control  and 
Message  Network  (CMN)  component  based  on  a  technology 
such  as  a  data  bus  or  a  packet-switched  network.  DTN 
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signalling  information,  in  the  form  of  circuit  control 
commands,  is  transmitted  by  the  CMN,  and  circuit  switching 
performed  by  an  Optical  Switch  Matrix.  The  DTN  component 
is  used  for  the  carriage  of  the  streaming-oriented  sensor  data. 
For  such  data,  a  connection  is  likely  to  be  established  on 
entering  a  system  mode  or  configuration,  and  to  remain  in  use 
until  the  system  is  re-moded  or  reconfigured,  a  period  of 
many  seconds.  In  addition  to  the  commands  for  the  switching 
of  the  DTN,  the  CMN  component  also  carries  user  message 
data.  CMN  messages  will  generally  be  smaller  than  those 
transmitted  via  the  DTN,  and  the  paths  they  take  are  likely  to 
vary  over  a  fairly  short  timeframe. 

The  basic  structure  of  the  MSN  is  shown  in  Fig.  7.  The  Link 
Control  Element  (LCE)  lies  at  the  centre  of  the  network,  and 
consists  of  a  non-blocking  Optical  Switch  Matrix,  a  Matrix 
Controller,  and  an  interface  to  the  CMN.  MSN  users  are 
connected  to  both  network  components. 
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Fig.  7:  Matrix  Switched  Network 


In  order  to  transfer  data  over  the  DTN,  an  MSN  user  initiates 
a  request  for  a  DTN  connection  to  another  user  by 
transmitting  a  request  for  a  physical  connection  over  the 
CMN  to  the  LCE.  If  the  LCE  is  able  to  meet  the  request,  it 
switches  the  Optical  Switch  Matrix  to  provide  the  physical 
connection,  enabling  the  two  users  to  communicate  with  each 
other.  It  must  be  ensured  at  the  system  design  time  that  the 
DTN  topology  is  able  to  support  the  required  system 
application  configurations.  While  the  connection  remains  in 
existence,  the  LCE  takes  no  further  part  in  the 
communication,  and  has  no  access  to  the  data  being  carried 
on  the  DTN.  In  addition  to  point-to-point  physical  DTN 
connections,  with  a  suitable  choice  of  Optical  Switch  Matrix 
architecture,  multicast  can  also  be  achieved,  and  multiple 
data  streams  may  also  be  multiplexed  over  a  single  DTN 
connection. 

When  user  data  is  transmitted  over  the  CMN,  only  the  CMN 
component  is  involved. 

The  implementation  of  both  network  components  will  be 
based  on  a  current  version  or  derivative  of  an  existing 
network  standard.  The  DTN  would  use  parts  of  the  physical 
layer  and  frame  structure  of  a  network  such  as  Fibre  Channel, 
or  possibly  elements  of  SCI  or  ATM,  while  candidates  for  the 
CMN  would  include  the  SAE  Linear  Token  Passing  Bus 
(Ref  8),  FDDI  (Ref  9),  SCI  (Ref  10),  in  its  forthcoming 
real-time  version,  or  ATM. 

Where  required,  for  instance  due  to  its  total  data  flow 
requirements,  a  network  user  equipment  may  be  equipped 
with  more  than  one  DTN  interface.  On  the  other  hand,  some 
additional  network  users  whose  data  transmission 
requirements  may  be  fulfilled  by  the  CMN  alone  may  be 
connected  only  to  this  component.  Systems  may  be  built  up  of 
multiple  LCEs,  with  each  LCE  intercoimected  by  DTN  and 
CMN  links,  as  shown  in  Fig.  8. 


Fig.  8:  Example  MSN  Architecture  with  Multiple  LCEs 


MiSiV  Protocol  Layers 

The  protocol  model  used  for  the  definition  of  the  MSN  is 
shown  in  Fig.  9.  It  is  based  on  the  ISO/OSI  model  (Ref  5), 
modified  for  real-time  use  by  the  removal  of  the  top  three 
layers  beneath  the  application,  and  the  addition  of 
Management  and  Time  Management  services. 
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Fig.  9:  Communication  Network  Protocol  Structure 

In  terms  of  the  above  model,  the  MSN  includes  the  Data  Link 
Layer  and  the  Physical  Layer,  shown  shaded  in  Fig.  9.  As 
depicted,  each  of  the  network  components  includes  its  own 
physical  layer,  and  lower  data  link  layer  sub-layer,  which 
includes  any  medium  access  control  functions  required  by  the 
CMN.  The  MSN  provides  a  single  Logical  Link  Control 
(LLC)  sub-layer,  which  performs  the  medium  access  control 
function  for  the  DTN  with  the  support  of  services  provided  by 
the  CMN.  The  LLC  integrates  the  functionality  of  the  two 
MSN  components  to  provide  a  single  set  of  network  services 
to  the  layer  above,  which  provide  for  both  DTN  and  CMN 
transfers.  The  services  are  based  on  those  of  the  standard  ISO 
8802-2  Local  Area  Network  LLC  (Ref  11).  Both  coimection- 
mode  and  connectionless-mode  services  are  offered,  the 
former  being  more  suited  to  streaming  data  to  be  carried  over 
the  DTN,  and  the  latter  to  the  system  control  and  message 
data  to  be  carried  over  the  CMN. 

In  systems  consisting  of  multiple  LCEs,  a  meshed  network 
would  be  used  between  the  LCEs,  providing  a  number  of 
different  possible  DTN  routes  between  a  given  pair  of  source 
and  destination  Network  Interface  Units  (NIUs).  The  LCE  to 
which  the  transmitting  NIU  is  attached  performs  a  routing 
function,  determining  the  step-by-step  route  to  be  set  up 
between  the  various  LCEs,  and  requesting  the  establishment 
of  this  path  by  the  use  of  CMN  messages.  A  network 
management  protocol  periodically  supplies  each  LCE  with 
the  network  state  information  for  the  complete  network,  this 
being  feasible  due  to  the  limited  size  of  even  a  relatively 
large  avionics  network. 
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There  are  a  number  of  possible  techniques  which  may  be 
adopted  in  order  to  offer  the  required  fault-tolerance  in  the 
MSN,  Redundancy  in  the  paths  between  the  LCEs  will  be 
provided  by  the  meshed  network,  and  additional  LCEs  and 
paths  could  be  added  to  increase  the  number  of  routing 
options.  Further,  the  number  of  different  possible  DTN  routes 
between  a  given  source  and  destination  NTU  may  also  be 
increased  by  the  provision  of  multiple  interfaces  on  network 
user  equipment.  The  routing  process  will  have  to  be  designed 
according  to  the  particular  techniques  chosen. 

Comparison  with  Alternative  Networks 

Of  the  potential  alternative  networks  to  the  MSN,  two  of  the 
most  relevant  are  ATM  and  SCI,  Each  of  these  was  originally 
devised  for  a  particular  area  of  application  which  differs 
significantly  from  an  IMA  system,  leading  to  certain 
limitations  in  their  applicability  to  an  IMA  system.  These 
two  network  technologies  have  been  assessed  and  compared 
with  the  MSN  using  simulation  and  analytical  techniques. 

ATM  is  a  connection-based  fast  packet-switching  technology 
aimed  in  the  first  instance  at  wide  area  networking 
applications,  in  which  it  is  achieving  a  high  and  ever-growing 
level  of  acceptance.  Current  restrictions  on  the  application  of 
ATM  to  IMA  include  the  overheads  of  the  connection  set-up 
procedure  on  the  transfer  of  randomly-directed  control  and 
message  data,  and  the  reliance  of  the  capacity  reservation 
procedure  on  a  more  stochastic  data  generation  process  than 
those  of  the  streaming  sources  of  an  IMA  system.  Further 
reservations  regarding  the  adoption  of  ATM  relate  to  the 
significant  risk  associated  with  upgrading  the  technology  to 
the  required  data  rates,  and  the  current  lack  of  market 
openness  due  to  the  incompatibility  of  commercial 
implementations . 

SCI  is  a  register-insertion-ring-based  technology  proposed 
primarily  for  closely-coupled  multiprocessing  applications, 
which  also  supports  longer-distance  communication.  The 
basic  ring  topology  offered  is,  however,  of  limited  suitability 
to  the  IMA  application,  and  the  development  of  the  necessary 
high-speed  SCI  packet  switches  is  still  at  relatively  early 
stage.  The  required  real-time  version,  featuring  prioritised 
transmission  and  fault-tolerance  features,  remains  at  the 
discussion  stage,  with  industrial  commitment  not  yet  secure. 

While  the  MSN  is  not  in  itself  a  COTS  network,  fully  COTS 
versions  of  ATM  and  SCI  cannot  be  used  in  an  IMA  system, 
as  discussed  above.  The  MSN  does,  however,  make  use  of 
COTS  network  technology  to  provide  a  communication 
network  tailored  to  real-time  distributed  systems,  with  two 
complementary  components  for  streaming  and  message  data. 
It  might,  for  instance,  employ  an  SCI  implementation  as  the 
CMN,  or  use  SCI  technology  by  adopting  its  frame  structure 
for  the  DTN  component.  Another  technology  with  which  the 
MSN  would  be  compatible  is  Wavelength  Division 
Multiplexing,  which  would  in  the  future  offer  an  upgrade 
path  to  greatly  extend  the  network  capacity 

Higher-Level  Protocol 

Returning  to  Fig.  9,  the  application  requires  a  high  quality 
end-to-end  communication  service  with  a  guaranteed  quality 
of  service,  offering  such  features  as  end-to-end  control,  error 
control,  flow  control,  segmentation  and  reassembly,  and 
multiplexing  and  demultiplexing.  This  service  is  provided  by 
the  Higher-Level  Protocol,  which  sits  above  the  MSN,  and 
which  might  be  split  into  the  Transport  Layer  and  the 
Network  Layer,  as  shown. 

The  requirements  for  the  higher-level  protocol  for  the 
communication  network  correspond  with  those  set  down  by 
the  SAE  for  such  an  application  (Ref  12).  These  differ  from 
those  for  a  typical  OSI  system  due  largely  to  the  real-time 


nature  of  the  IMA  application  and  its  strict  fault-tolerance 
requirements.  For  the  IMA  application,  these  factors  result  in 
the  implementation  of  fault-tolerance  features  at  a  lower 
protocol  level  in  hardware,  and  consideration  of  the  use  of  a 
single  protocol  layer  rather  than  the  OSI-based  Transport  and 
Network  layers.  The  types  of  service  to  be  provided  by  the 
higher-level  protocols  include  connection-oriented  and 
coimectionless  data  transfer,  including  multicast;  time 
management,  including  synchronisation;  and  management 
services  including  configuration,  monitoring,  control,  and 
test.  It  should  be  possible  to  fulfil  the  requirements  by 
adopting,  and  modifying  if  necessary,  a  current  version  or 
future  development  of  such  real-time  protocols  as  the  GAM- 
T-103  series  or  XTP  (Ref  13),  or  possibly  a  development  of 
OSI  TP4  or  TCP/IP. 

Whichever  basis  is  used  for  the  higher-level  protocol,  the 
interface  between  the  higher-level  protocol  and  the 
application  will  be  standardised,  as  the  Network-Independent 
Interface  (NH).  This  will  contain  a  parameterised 
specification  of  the  quality  of  service,  and  so  de-couple  the 
application  from  the  network  implementation,  allowing  future 
advances  in  the  network  technology  to  be  exploited  by  the 
application. 

In  terms  of  the  IMA  software  architecture  concept  (see  Sec. 
3.2),  the  Nil  is  a  component  of  the  MOS.  It  forms  part  of  the 
interface  between  the  communication  network,  which  is 
implemented  in  the  Module  Support  Layer  and  network- 
specific  hardware/firmware,  and  those  communication 
functions  of  the  Communication  System  which  are  common 
to  both  internal  and  external  module  communication,  which 
are  implemented  as  part  of  the  Operating  System  Layer. 

3. 1.3.  Concept  Demonstration 

In  order  to  validate  the  MSN  concept,  an  MSN  functional 
prototype  is  being  demonstrated  as  part  of  the  IMA 
Demonstrator.  The  implementation  is  based  on  commercial 
standards  and  components,  as  far  as  possible,  and  an 
electrical  switch  matrix  is  used.  The  DTN  physical  layer  and 
frame  structure  is  based  on  an  implementation  of  Fibre 
Channel,  and  the  CMN  is  implemented  as  an  FDDI  network. 
The  main  MSN  features  are  implemented  in  the  demonstrator 
as  follows; 

•  Network  topology  comprising  two  complementary 
components,  ie.  circuit-switched  DTN  and  token  ring- 
based  CMN. 

•  Functional  prototype  Logical  Link  Control  (LLC)  level 
protocol. 

•  Provision  for  multiple  NIUs  per  DPM  for  redundancy 
purposes. 

•  Compatibility  with  the  message-passing  scheme  of  the 
software  architecture  concept. 

•  Framework  for  a  Network  Independent  Interface. 

•  Demonstration  performance  targets  for  Data  Rate, 

Latency,  Linking  Time. 

A  4x4  LCE  has  been  built,  together  with  four  NIUs.  The 
DTN  component  uses  a  FibreExpress  Fibre  Channel 
implementation  with  a  multimode  electro-optical  converter  to 
provide  a  peak  data  rate  of  400  Mbit/sec,  while  a  100 
Mbit/sec  Interphase  single-attached  FDDI  implementation 
and  concentrator  are  used  for  the  CMN.  The  LCE  comprises  a 
custom  board  carrying  a  TriQuint  electrical  crossbar  switch 
and  electro-optical  converters,  together  with  a  single  board 
computer  and  FDDI  interface  with  the  matrix  controller 
software.  Each  NIU  consists  of  a  VME-based  Fibre  Channel 
interface  and  a  single  board  computer  and  PCI  Mezzanine 
Card  FDDI  interface  with  the  LLC  software,  and  interfaces 
with  its  host  via  a  VME  interface. 
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As  a  first  stage  in  the  integration  of  the  network,  a  self- 
contained  MSN  Prototype  System  has  been  built,  consisting 
of  an  LCE,  and  four  NHJs  in  one  rack  driven  by  one  single 
board  computer.  This  is  to  be  used  to  conduct  functional 
tests,  and  performance  tests  addressing  such  key  parameters 
as  throughput,  transfer  latency,  linking  time  and  error  and 
loss  rates,  from  which  the  results  will  be  assessed  against  the 
design  parameters.  After  completion  of  tests  on  the  MSN 
prototype  system,  the  individual  NTUs  will  be  removed  and 
distributed  to  and  integrated  into  the  three  DPMs  of  the  IMA 
Demonstrator,  giving,  together  with  the  LCE,  the 
configuration  shown  in  Fig.  6.  The  IMA  Demonstrator  will 
then  be  used  for  further  demonstration,  as  described  in 
Sec.  4. 

Following  the  completion  of  the  current  concept  validation 
work,  it  is  planned  to  continue  the  development  of  the  MSN 
with  the  support  of  the  IMA  Demonstrator.  Proposed 
developments  for  the  short-term  include  developing  the 
Logical  Link  Control  protocol  sub-layer  to  include  fault- 
tolerance,  to  add  inter-LCE  routing,  and  to  improve  its 
performance.  The  optimal  choice  of  network  technology  for 
the  CMN  should  be  kept  under  review,  as  should  the 
development  of  the  technology  for  the  optical  switch  matrix, 
and,  when  this  is  sufficiently  well  advanced,  the  electrical 
switch  of  the  LCE  should  be  replaced  by  an  optical  version. 
The  definition  of  the  Network  Independent  Interface  should 
be  developed,  and  the  suitability  of  the  candidate  higher-level 
protocols  investigated. 

3.2.  Software  Architecture  Concept 

3. 2. 1  .Requirements 

It  is  one  of  the  aims  of  Integrated  Modular  Avionics  that 
whereas  systems  should  be  open  to  the  introduction  of  new 
hardware  in  much  shorter  cycle  times  than  with  previous 
generations  of  federated  avionic  systems,  IMA  software 
systems  should  remain  in  use  over  a  longer  timeframe  than 
with  the  previous  project-specific  software  systems.  This 
results  in  the  need  to  adapt  the  avionic  software  system  more 
frequently  to  new  hardware  environments,  for  instance  with 
the  introduction  of  new  processors  or  new  communication 
networks,  for  instance  to  achieve  performance  improvements 
or  to  replace  obsolete  components.  The  resulting 
requirements  for  software  portability  and  re-usability  both 
contribute  to  lowering  life-cycle  costs,  and  are  two  of  the 
driving  requirements  on  the  IMA  software  concept.  A  further 
driver  is  the  requirement  to  perform  fault-tolerance  on  a  hard 
real-time  system  potentially  subject  to  flight-  and  mission- 
criticality  constraints. 

The  use  of  the  layered  structure  of  the  IMA  software 
architecture  shown  in  Fig.  2  enables  the  fulfilment  of  the 
requirements  for  portability,  re-usability  and  fault-tolerance. 
The  high  level  Application  to  Operating  System  (APOS) 
interface  is  implemented  by  a  set  of  Operating  System  Layer 
(OSL)  services  which  allow  the  Functional  and  System 
Applications  to  access  the  distributed  Operating  System 
software,  including: 

•  Transparent  communication  services,  via  virtual 
communication  channels 

•  Resource  mapping  and  (re-)configuration  services 

•  Fault  detection  and  isolation  services. 

These  operating  system  services  provide  lower-level  support 
to  the  System  Applications  which  provide  the  actual  system 
management  functionality,  for  such  functions  as  the 
reconfiguration  of  resources  and  applications. 

To  ease  the  integration  of  new  hardware  into  the  system,  a 
standard  interface  is  introduced  below  the  operating  system. 
The  Module  Support  Layer  (MSL)  implements  hardware- 


dependent  functions  which  support  the  operating  system.  By 
defining  and  standardising  the  MSL  to  Operating  System 
(MOS)  interface,  the  effects  of  changes  in  the  hardware  may 
be  restricted  to  the  MSL.  The  Network  Independent  Interface 
of  the  communication  network  will  form  part  of  the  MOS. 

Blueprints  represent  a  structured  description  of  the  avionic 
system.  The  Application  Blueprints  contain  the  description  of 
the  application  from  a  logical  point  of  view,  including,  for 
example,  the  resource  requirements  and  the  virtual 
communication  channels.  The  physical  aspects  of  the  avionic 
system,  such  as  the  processors  and  physical  communication 
channels,  are  described  in  the  Resource  Blueprints.  The 
mapping  between  physical  and  logical  descriptions  is 
provided  by  the  System  Blueprints,  in  which,  for  example, 
the  applications  are  mapped  onto  processors.  Changes  in  the 
underlying  hardware  and  related  MSL  are  accommodated  by 
modifying  the  blueprints. 

According  to  the  concept  as  implemented  in  the  IMA 
Demonstrator,  the  mapping  represented  in  the  system 
blueprints  is  a  static  mapping,  determined  at  system  design 
time.  In  the  future,  it  should  be  possible  to  extend  this  to 
implement  dynamic  mapping,  determined  during  run-time, 
while  retaining  the  basic  blueprint  structure.  In  this  case,  the 
system  blueprint  would  contain  mapping  rules  which  would 
be  applied  at  start-up  and  during  run  time  to  the  application 
and  resource  blueprints,  in  order  to  determine  the  mapping  to 
be  used. 

The  blueprints  and  the  well-defined  APOS  and  MOS 
interfaces  implement  a  virtual  system  concept,  which  ensures 
that  as  many  system  control  tasks  as  possible  are  performed 
in  a  project-independent  and  implementation-independent 
manner.  This  strategy  contributes  to  fulfilling  the  IMA 
objectives  throughout  the  system  life-cycle.  During  system 
development,  it  minimises  the  costs  of  tailoring  the  IMA 
system  to  a  project-specific  implementation.  During 
subsequent  modification  and  extension  of  the  system,  the 
system  engineering  effort  is  reduced  by  the  software 
portability  and  reusability  achieved. 

3. 2. 2.  Communication  System 
Concept 

The  IMA  communication  system  must  be  capable  of  fulfilling 
the  IMA  requirements  for  the  transfer  of  large  volumes  of 
high  rate  real-time  data,  between  both  applications 
distributed  between  processing  modules,  and  the  various 
external  components  such  as  sensor  front  ends  and  displays. 

One  of  the  main  features  of  the  IMA  communication  software 
architecture  is  the  provision  of  virtual  communication 
channels  between  the  applications,  in  order  to  perform 
communication  independently  of  the  current  realisation  of  the 
physical  communication  channel  and  its  protocol. 

Fig.  10  shows  the  communication-related  aspects  of  the 
software  architecture  concept. 


Fig.  10:  The  Communication  System 
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Demonstration 

The  Communication  Server  implements  the  Operating 
System  Layer  services  of  the  communication  system;  three 
groups  of  services  have  been  implemented. 

The  first  group  of  services  relates  to  connection 
establishment.  The  virtual  connections  will  usually  be  pre¬ 
defined  in  the  blueprints,  and  so  such  connection  services  as 
"defme_connection"  and  "request_disconnection"  will  be 
executed  by  the  communication  system  at  system  start-up, 
mode-change  or  during  reconfiguration  following  the 
occurrence  of  a  failure,  on  the  basis  of  the  information  in  the 
blueprints.  During  normal  operation,  the  applications  will  use 
the  pre-defined  connections  by  means  of  the  "use_connection" 
service. 

A  group  concept,  derived  from  the  Message  Passing  Interface 
standard  (Ref  14),  is  implemented  in  the  second  set  of 
communication  services.  These  services  allow  the 
management  of  groups  of  virtual  communication  channels, 
which  is  of  great  use  in  implementing  a  fault-tolerant 
concept.  In  order  to  activate  communication  to  a  stand-by 
module,  for  instance,  the  only  action  to  be  performed  would 
be  to  add  the  connection  to  or  from  the  stand-by  module  to 
the  communication  group.  Messages  would  then  be  sent  or 
received  automatically  by  the  new  group  member  without 
explicitly  notifying  the  other  applications  involved. 


begin 

name  :=  applicatibn_l; 

begin_app 

begin_com 

chi  :=  (srcl,  snk2);  , 

taskl  :=  (srcljfSnkf);  , 

task2  ;=  (snk2);  . 

end_com 

end_app 

end 

Fig.  12:  Example  System  -  Application  Blueprint 

Fig.  13  shows  the  hardware  block  diagram  of  the  example 
system,  depicting  its  physical  organisation. 


1  1 

processor  1 

I 

processor  2 

Channel  1 

Channel  2 


-|  Sensor^ 


Fig.  13:  Example  System:  Hardware 


The  last  group  of  communication  services  includes  the 
standard  well-known  data  transfer  services,  such  as  "send" 
and  "receive".  An  additional  service  included  is  the  atomic 
multicast  service,  where  atomic  implies  that  either  all  or  none 
of  the  recipients  will  receive  the  message.  This  service  is 
implemented  by  the  group  concept  described  above.  It  is 
mainly  used  by  the  fault  and  configuration  manager,  and 
allows  the  delivery  of  reconfiguration  information  to  a 
distributed  system,  as  well  as  keeping  the  configuration 
information  consistent. 

The  integration  of  the  communication  aspects  of  the 
blueprints  into  the  communication  system  software  has  been 
performed  by  the  use  of  a  Management  Information  Base 
(MIB).  A  Blueprint  Interpreter  reads  the  blueprints  only  once 
at  system  initialisation  time,  following  which  the  MIB 
provides  access  to  the  blueprint  information  during  run-time. 
This  use  of  this  concept  simplifies  the  alteration  of  the 
blueprints  during  the  test  and  system  integration  phases. 

Fig.  11  shows  a  very  simple  communication  scenario  between 
two  applications.  It  is  used  to  demonstrate  the 
implementation  of  the  communication  aspects  in  the 
blueprints.  The  communication  between  applications  is 
shown  from  a  logical  point  of  view. 


Fig.  11:  Example  System  -  Logical  Description 

Fig.  12  shows  the  communication  aspects  of  the 
corresponding  application  blueprint  for  Application  1 ;  that  for 
Application  2  would  be  similar. 


Part  of  the  physical  organisation  is  described  in  the  resource 
blueprint  as  shown  in  Fig.  14. 

begin 

name  ,  resource_l; 

begm_res 

beginchannel 

id  :  chaMell; 

id  channel2; 

end_channel 
:  begin_proc 

id  :=  prod; 

id:-proc2; 

end_proc 

end_jes 

end 

Fig.  14:  Example  System  -  Resource  Blueprint 

The  elements  of  the  application  blueprints  (eg.  applications, 
virtual  communication  channels)  have  to  be  mapped  onto  the 
available  resources.  For  the  example  system,  Fig.  15  shows 
the  physical  distribution  of  the  applications  on  processors, 
and  the  connections  via  the  physical  channels. 


cM,ch2 


Resource  Blueprint  Elements;  Standard  script 

Application  Blueprint  Elements:  Italic  script 


Fig.  15:  Example  System  -  System  Distribution 
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The  physical  representation,  ie.  the  mapping  of  the 
Application  Blueprints  onto  the  Resource  Blueprints,  is 
described  by  the  System  Blueprints,  as  shown  for  the 
example  system  in  Fig.  16. 

begin 

name:  ^  example_system; 

begm_sys 
begin  proc 
■  taslci 
taslc2: 
tasks 
end_proc 
:begin_com 

applieationjl  .cHl 
T  : application^ l.ch2 
application_2.ch3 
end_CQm 
end_,sysi 
end 

Fig.  16:  Example  System  -  System  Blueprint 

In  conclusion,  the  implementation  of  the  communication 
system  using  the  virtual  channel  concept  and  communication 
information  derived  from  blueprints  has  demonstrated  a 
concept  which  supports  hardware  portability  and  software  re¬ 
usability. 

Following  the  completion  of  demonstration  of  the 
implemented  services,  it  is  intended  to  assess  the  additional 
overhead  imposed  by  the  communication  system  in  relation  to 
the  time  taken  to  transfer  messages  over  the  underlying 
communication  chaimel,  and  to  investigate  the  introduction  of 
prioritised  channels  in  order  to  minimise  its  possible 
consequences. 

3. 2. 3.  Fault  Management  System 
Concept 

One  of  the  prime  requirements  on  the  IMA  system  is  that  it 
provide  continued  operation  in  the  presence  of  faults. 

Fig.  17  indicates  the  fault  management-specific  aspects  of  the 
software  architecture  concept. 


Fig.  17:  The  Fault  Management  System 

The  main  services  of  the  IMA  fault  management  system  may 
be  broken  down  as  follows: 

•  System  Monitoring  and  Diagnosis 

•  Fault  Detection 

•  Fault  Isolation 

•  Fault  Recovery. 

System  Monitoring  and  Diagnosis  services  determine  the 
status  of  the  system  components  by  a  combination  of  active 
testing  and  passive  data  collection  and  evaluation.  An 
example  of  active  component  testing  is  the  self-test  logic  of  a 
hardware  clock.  In  the  passive  process,  information  about  the 
system  behaviour  is  gathered,  and  then  evaluated,  in  order  to 
assess  the  state  of  the  components,  for  example  by  monitoring 
the  processor  throughput  in  order  to  detect  system  overload. 


These  services  will  largely  be  implemented  as  Built-In  Test 
services  in  the  Module  Support  Layer. 

Fault  Detection  services  are  concerned  with  determining 
when  a  failure  has  occurred  in  the  system.  Fault  Detection 
services  request  the  status  of  system  components  from  the 
System  Monitoring  services,  and  compare  it  to  the  specified 
system  behaviour. 

Fault  Isolation  services  attempt  to  determine  the  location  of 
the  faulty  component  and  to  disable  and  segregate  this 
component  from  the  rest  of  the  system.  They  also  inform  the 
Fault  Recovery  services  of  the  faulty  component  and  its 
detected  health  status. 

Both  the  Fault  Detection  and  Fault  Isolation  services  are 
supplied  by  the  Health  Monitoring  function  implemented  in 
the  Operating  System  Layer. 

Fault  Recovery  services  are  employed  when  a  failure  cannot 
be  masked  out  at  a  lower  level.  Their  task  is  to  restore  the 
system  operating  capability  on  the  basis  of  the  recovery 
mechanisms  specified  in  the  blueprints.  Firstly,  the  blueprint- 
based  information  on  the  recovery  mechanism  is  retrieved 
from  the  Management  Information  Base:  this  might  define  a 
graceful  degradation  mechanism  in  order  to  ensure  the 
retention  of  flight-critical  and  mission-critical  functions.  The 
reconfiguration  mechanism  may  be  static  or  dynamic.  The 
specified  reconfiguration  itself  is  then  performed,  and  all 
relevant  elements,  including  logging  and  maintenance 
systems,  informed  accordingly. 

Demonstration 

Taking  as  an  example  the  two  applications  application_l  and 
application_2.  Initially,  application_l  is  the  active 
application,  and  application_2  a  hot  stand-by  implementation, 
hr  the  case  of  a  recovery  from  a  functional  application  failure 
of  application  !,  the  sequence  of  actions  performed  during 
reconfiguration  might  be  as  follows: 

•  Deactivate  the  failed  application,  application_l 

•  Activate  the  hot-standby  application,  application_2 

•  Inform  system  partners  of  application_2  reconfiguration 

•  Perform  logging. 

This  reconfiguration  process  has  been  implemented  in  the 
blueprints  as  shown  in  Fig.  18. 

beginjeconfig 

ifehi  ;=application_l;  .  „ 

item_siatus  :=  active; 
failime_class;=application; 
failure  ;=  crash; 
begin_step 

stepmumber 1 ; 

reconfig  action  :=  deaCtivate_current_item; 
fecorifig_class  :=  application; 
reconfig_item  :=  application_l; 
end_step 
begin_step 

step__riumbcr  :=  2; 

rec6hfig_action  activate_hot_stand_by; 
reconfigmlass  :=  application; 
reconfigfitem  :=  application_2; 

end_sfep  ■  .  . 

'  'begiirntep. 

step_number  :=  3; 

recbnfig  action  actualize^artner_conflg_info; 
reconfig_class  ;=  appiichfibn; 
reconfigjteitt  :==  appHcatidh^ 
end_step 
erid_reconflg 

Fig  18:  Reconfiguration  Aspects  in  Blueprints 


:  pCOCl  ; 

:=  proc2; 

:=  proc2; 

:-  ;  channel!; 
K  :  chatmell; 
;=  channel; 
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Fig.  19  illustrates  another  example  of  a  reconfiguration 
process.  It  shows  a  failure  of  an  underlying  physical 
communication  channel  during  virtual  inter-process 
communication. 


Fig.  19:  Reconfiguration  Example 


Following  reconfiguration,  whereas  the  mapping  of  the 
virtual  channel  onto  the  physical  channel  has  been  altered, 
from  the  logical  point  of  view  the  inter-process 
communication  between  Task  1.1  and  Task  2.1  remains 
unaffected.  Thus,  the  virtual  communication  channel  will 
remain  unchanged. 

The  design  of  much  of  the  software  system  is  affected  by  the 
fault  management  system: 

•  During  reconfiguration,  almost  the  complete  software 
system,  including  both  the  operating  system  and 
applications,  is  involved. 

•  The  fault  management  strategy  is  closely  interrelated  with 
the  system  management  for  resource  allocation  and 
scheduling  during  initialisation  and  during  mode¬ 
changing  at  run-time. 

•  There  is  a  high  level  of  interdependency  with  the 
communication  system,  in  that  a  well  designed 
communication  system  and  multi-cast  service  are 
essential  for  the  fault  and  configuration  management 
processes. 

It  is  noted  that  during  the  design  phase  it  will  be  a  task  of 
considerable  scope  and  importance  to  identify  the  possible 
failures  and  their  corrective  actions,  in  order  to  supply 
information  for  the  blueprints  which  will  guarantee  a  stable 
and  reliable  avionic  system  under  real-time  conditions. 

4.  FUNCTIONAL  APPLICATION  DEMONSTRATION 

The  communication  network  and  software  architecture 
components  developed  as  described  above  will  be  integrated 
into  the  IMA  Demonstrator,  and  the  communication  and  fault 
management  capability  of  the  IMA  Demonstrator 
demonstrated.  This  will  include  the  demonstration  of 
representative  functional  applications,  in  order  to  show  that 
the  proposed  IMA  concepts  will  support  applications  typical 
of  future  avionic  systems. 

The  avionics  application  chosen  for  this  purpose  is  a  flight 
guidance  application,  which  results  in  the  production  of  a 
two-dimensional  primary  flight  display  and  a  three- 
dimensional  terrain  grid  display  on  a  cockpit  monitor.  It 
relies  on  the  IMA  Demonstrator  for  variable  data  bandwidth 
transfer,  real-time  process  execution  and  inter-process 
communication,  to  provide  its  full  functionality  and 
pprformance.  The  application  will  be  demonstrated  in  a 
dynamic  mission  scenario  generated  by  an  aircraft  simulation 
environment. 

The  general  view  of  the  IMA  architecture  for  the  functional 
application  demonstration  is  as  shown  in  Fig.  5,  and  the 
functional  layout  is  shown  in  Fig.  20. 


Fig.  20:  Functional  Applications  Demonstration 

The  application  will  be  split  up  into  five  processes  to  allow  a 
distributed  implementation  on  a  number  of  DPMs.  Dynamic 
environmental  data  is  derived  from  an  aircraft  simulator 
system  and  transferred  to  an  interface  process  (not  shown)  on 
the  first  DPM  via  an  Ethernet  test  interface.  The  basic 
rendering  will  be  performed  by  a  Digital  Graphics  Module 
(DGM),  which  is  connected  to  a  second  DPM  via  an  interface 
process  and  the  backplane  VMEbus. 

The  five  application  processes  execute  in  real-time,  and  may 
be  located  on  and  execute  on  any  of  the  system's  DPMs.  The 
data  transfer  required  between  the  processes  covers  various 
bandwidths:  aircraft  data  will  be  transferred  at  a  high 
transmission  rate  via  small  data  messages,  whereas  terrain 
data  transfer  is  event-driven  and  comprises  large  data 
messages.  Real-time  performance  of  all  the  processes  is 
necessary  to  maintain  a  high  display  update  rate  in  order  to 
reflect  the  current  simulated  aircraft  position  and  attitude. 

The  application  processes  will  use  the  communication 
services  of  the  operating  system  in  order  to  exchange  their 
data,  allowing  them  to  operate  independently  of  the  particular 
media  and  routing  determined  by  the  operating  system  and 
lower  layers.  In  order  to  demonstrate  the  reconfiguration  and 
fault-tolerance  capabilities  of  the  IMA  architecture,  one  of  the 
application  processes  will  be  instanciated  twice,  firstly  as  a 
primary  executing  process,  and  secondly  as  hot-standby 
process  on  another  DPM.  During  execution,  the  DPM  which 
hosts  the  primary  executing  process  will  be  switched  off  and 
the  hot-standby  process  on  the  other  DPM  will  take  over  as  a 
backup,  without  any  effect  on  the  application's  functionality 
or  performance. 

5.  CONCLUSION 

With  the  construction  of  the  IMA  Demonstrator,  a 
demonstration  environment  has  been  created  for  continuing 
IMA  activities.  In  the  activities  addressed  in  this  paper,  key 
IMA  concepts  for  the  communication  network  and  the 
software  architecture  have  been  refined  and  validated. 

For  the  future,  it  is  intended  to  build  on  the  IMA 
Demonstrator  to  further  develop  the  concepts  for  the  key 
areas,  and  a  number  of  developments  would  be  suitable  for 
consideration.  For  the  software  architecture,  the 
implementation  of  the  software  concept  and  its  operating 
system  would  be  extended.  Future  development  of  the 
communication  network  would  include  the  development  of 
the  Logical  Link  Control  protocol,  the  investigation  of  higher- 
level  protocols  and  the  definition  of  the  Network  Independent 
hiterface,  and  eventually  the  application  of  an  optical  switch 
matrix. 
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7.  ABBREVIATIONS 

AMT  Analyse,  Monitor,  Test 

APOS  Application  to  Operating  System  (interface) 

ASAAC  Allied  Standard  Avionics  Architecture  Council 

ATM  Asynchronous  Transfer  Mode 

CEPA  Common  European  Priority  Area 

CMN  Control  and  Message  Network 

COTS  Commercial  Off-The  Shelf 

DGM  Digital  Graphics  Module 

DPM  Data  Processing  Module 

DTN  Data  Transmission  Network 

EUCLID  European  Co-operation  for  the  Long  Term  in 
Defence 

FDDl  Fibre  Distributed  Data  Interface 

GOA  Generic  Open  Architecture 

IMA  Integrated  Modular  Avionics 

ISO  International  Organisation  for  Standardisation 

LCE  Link  Control  Element 

LLC  Logical  Link  Control 

MIB  Management  Information  Base 

MOS  Module  to  Operating  System  (interface) 

MSL  Module  Support  Layer 

MSN  Matrix  Switched  Network 

Nn  Network-Independent  Interface 

NTU  Network  Interface  Unit 

OSE  Open  Systems  Environment 

OSI  Open  Systems  Interface 

OSL  Operating  System  Layer 

PCI  Peripheral  Component  Intercoimect 

POSIX  Portable  Operating  System  Interface 

RTP  Research  and  Technology  Project 

SAE  Society  of  Automotive  Engineers 

SCI  Scalable  Coherent  Interface 

TCP/IP  Transmission  Control  Protocol  /  Internet  Protocol 

VME  Versa-Module  Europe 

XTP  Express  Transfer  Protocol 
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Abstract 

In  this  study,  radome  structures,  located  in  the  nose 
seetion  of  aircrafts,  which  protect  radar  antennas 
from  adverse  environmental  effects,  fit  to  aircraft 
structures  aerodynamically  but  which  differ  from 
other  parts  of  aircrafts  in  terms  of  electrical  features 
have  been  examined  basically.  Effects  of  radome 
structural  .anomalies  to  radome  electrical 
performance  have  been  investigated  by  bonding 
mica  plates  at  some  parts  of  electromagnetic 
window  section  of  an  F-4  nose  radome  which  differ 
the  thickness  of  the  structure.  Transmission  loss, 
boresight  error,  boresight  error  measurements,  have 
been  achieved  via  B-350A  Test  Utility  System. 
Consequently,  experimental  analysis  of  anomalies 
which  occur  as  variation  at  density  and  thickness 
of  radome  structures  have  been  evaluated. 

l.Introduction 

Protective  dielectric  structure  which  is  called  as 
“radardome”  or  shortly  “radome”  is  used  for 
protection  of  microwave  or  milimetric  wave 
antennas  from  adverse  environmental  effects  (1). 
Operation  frequency  range  of  radome  is 
approximately  between  1  GHz  and  1000  GHz. 
Radomes  are  generally  manufactured  from  low  loss 
dielectric  material  whose  thickness  is  proportional 
to  the  wavelength  of  the  antenna  covered  and 
designed  according  to  aerodynamical  characteristics 
of  plane  of  use. 

Z.Radome  Stnictures 

Aircraft  nose  radomes  are  classified  as  : 

A)  Single  layer  (monolithic) 

B)  A-Sandwich 

C)  B- Sandwich 

D)  C- Sandwich 

E)  Multiple  layer  sandwich 

F)  Dielectric  layers  with  metal  inclusions 
according  to  their  structures  (2). (Figure.  1.) 

Monolithic  layer  consists  of  a  single  slab  of 
homogeneous  dielectric  material.  Materials  for  this 
type  have  included  fiberglass-reinforced  plastics, 
ceramics,  elastomers  and  monolithic  foam.  The 
optimum  thickness  for  a  single  layer  is  a  multiple  of 
a  half  wavelength  in  the  dielectric  material  at  the 
appropriate  incidence  angle,  but  many  single  layer 
radomes  are  simply  thinwall  approximations  to  the 
zero  thickness  case. 


A  B  C 


D  E'  F 


Figure.1.:  Radome  Structures 

A  commonly  used  radome  wall  cross  section  is  the 
A-sandwich  which  consists  of  two  relatively  dense 
thin  skins  and  a  thicker  low  density  core.  The  skins 
are  generally  fiberglass  reinforced  plastics  and  the 
core  is  a  foam  or  honeycomb.  This  configuration 
exhibits  high  strength-to-weight  ratios.  As  a  mle, 
the  skins  of  the  sandwich  are  made  symmetrical  or 
of  equal  thickness  to  allow  midband  cancellation  of 
reflection,  ft  gives  perfect  electrical  performance 
below  6  GHz.  It  allows  cancellation  of  side  band 
reflections. 

B-  sandwich  is  a  three  layer  configuration  whose 
skins  have  a  dielectric  constant  lower  than  that  of  a 
core  material.  This  structure  is  not  commonly  used. 
The  C-sandwich  is  a  five-layer  design  consisting  of 
outer  skins,  a  center  skin  and  two  intermediate 
cores.  The  symmetrical  C-sandMch  can  be  thought 
of  as  two  back-to-back  A  sandwiches.  This 
configuration  is  used  when  the  ordinary  A  sandwich 
will  not  provide  sufficient  strength,  or  for  certain 
electrical  performance  characteristics. 

Multiple  layer  sandwiches  of  7,  9,  1 1  or  more  layers 
are  sometimes  considered  when  great  strength, 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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good  electrical  performance  relatively  light  weight 
are  required.  Some  of  these  designs  have  used  thin 
layers  of  fiberglass  laminates  and  low  density  cores 
to  attain  high  transmission  performance  over  large 
frequency  bands. 

Metal  inclusions  have  been  considered  for  use  with 
dielectric  layers  to  achieve  frequency  filtering, 
broad-frequency-band  performance,  or  reduced¬ 
thickness  radomes.  Thin  layers  of  metal  inclusions 
exhibit  the  characteristics  of  lumped  circuit 
elements  shunted  across  a  transmission  line.  For 
example,  a  grid  of  parallel  metal  wires  exhibits  the 
properties  shunt-inductive  susceptance. 

Nose  radome  of  an  F-4E  aircraft  which  has  been 
used  in  this  study  has  a  structural  design  called  as 
“filament-wound”  (3).  It  is  a  single  layer  type. 
Layers  consisting  of  fiberglass  are  wrapped 
perpendicular  around  each  other  in  accordance  with 
the  conical  shape  of  radome  and  bonded  with  resin. 
Then  thermal  curing  operation  is  applied  to  this 
structure.  The  shape  of  radome  is  “tangent  ogive” 
which  fits  to  aircraft  structure  aerodinamically 
(Figure.2). 


INCIDENT  PLANE 
WAVE 


Figure.2. :  Antenna-Radomes  Geometry 

Electrical  characteristics  of  filament  wound 
radomes  and  other  wall  structure  types  are  given  in 
Table- 1.  These  characteristics  are  function  of 
density  and  resin  compositions(4). 


Table.  1.:  Electrical  characteristics  of  radome  wall 
structures 


Type 

Er 

Loss  Tang. 

Polyester-glass 

3.6-5 

0.01-0.02 

Epoxy-glass 

3.6-5 

0.01-0.02 

Fused  slica 

3.4 

0.008 

Alumina 

9 

0.003 

Radome  wall  structures  combine  material 
technology  and  electrical  characteristics  of  plane 
layer.  Single  layer  wall  stnicture  consists  of  single 
layer  dielectric  material  and  its  thickness  is  less 
than  1/10  X.  For  adequate  strength  at  higher 
frequencies,  the  monolithic  wall  thickness  is  chosen 
according  to  ; 


n  A 

d=  -  (1) 

2  (e,.-Sin^9)'^" 

Where  n  is  an  integer  with  a  value  of  “1”  for  X/2 
wall.  X  is  wavelength  of  free  space,  Sr  is  relative 
dielectric  constant  and  9  is  incidence  angle.  “9“  is 
also  called  as  “design  angle”.  Reflection  is  zero  at 
this  angle  for  perpendicular  and  circular 
polarization.  Maximum  and  equal  transmittance 
will  be  obtained  and  equal  insertion  phase  delays 
will  be  introduced  by  the  plane  dielectric  sheet. 
(3)(figure  3). 


Figure.3.:  Power  transmittance  (upper  curves)  and 
insertion  phase  delay  versus  incidence  angle  for 
alumina  half-wave  panel  having  a  design  angle  of 
55°  for  parallel  (solid  curves)  and  perpendicular 
dash)  polarizations  (Sr=9.3,  tan  6  =0.0003,d=0.17A. ) 

A  radome  always  changes  the  electrical 
performance  of  the  antenna  because  of  wave 
reflections  and  refractions  at  interfaces  between 
material  media  and  because  of  losses  in  the  radome 
materials.  These  changes  manifest  themselves  as  : 
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Figure.4.:  Effects  Of  Distortion  In  Antenna 
Diagram 

Pattern  distortion  including  changes  in  gain, 
sidelobe  levels,  beam  width,  null  depth  and 
polarization  characteristics(Figure.4).  Excessive 
reflections  from  the  radome  may  cause  magnetron 
pulling.  For  high-power  applications,  excessive 
losses  in  the  radome  material  may  raise  its 
temperature-  to  a  point  at  which  its  structural 
properties  and  electrical  performance  are  degraded. 
Radome  losses  also  will  raise  the  system  noise 
temperature.  Radome  effects  can  be  qualitatively 
explained  and  understood  in  terms  of  TEM  (plane) 
wave  propagation  through  and  reflection  from 
planer  dielectric  each  point.  Waves  emanating  from 
the  enclosed  transmitting  antenna  are  also 
considered  to  be  locally  plane  at  each  point  of 
incidence  on  the  radome  wall.  The  reflected  and 
transmitted  waves  can  then  be  approximated  from 
plane-sheet  theory'. 


The  transmission  properties  of  a  plane  dielectric 
sheet  vary  with  frequency,  incidence  angle,  and 
polarization  of  the  incident  plane  wave.  (Figure.5) 


Figure.5.:Plane-wave  propagation  through  a  flat 
dielectric  panel 

The  plane  of  incidence  is  defined  by  unit  normal 
(rios)  and  the  direction  of  wave  propagation  (k^). 
The  incidence  angle  is  given  by  Sin  (k  X  iios). 


Arbitrary  wave  polarizations  are  resolved  into  an 
electric  field  component  perpendicular  to  the  plane 
of  incidence(Ea).  The  power  transmission 
coefficient  (transmittance)  and  insertion  phase 
delay  (IPD)  are  generally  different  for  the  two 
polarizations.  The  electrical  characteristics  of  flat 
planes  are  important  because  radome-wall  design  is 
based  on  them. 

S.Effect  Of  Radomes  On  Antenna  Performance 

Radomes  affect  antenna  performance  as  follows 
while  they  are  protecting  antenna  from  adverse 
environmental  effects. 

1. Beam  Deflection;  It  is  shifting  of  electrical  axis 
and  is  a  critical  effect  for  seaker  radars. 

2.  Transmission  Loss:  It  is  the  measured  loss  of 
energy  caused  by  reflection  or  absorption  of 
incoming  beam  to  the  radome. 

3.  Reflected  Power:  It  causes  mismatching  of 
antennas  at  small  radomes  and  sidelobes  at  pattern 
graphics  at  large  radomes. 

4. Secondary  Effects:  It  disturbs  planar  polarization 
and  causes  antenna  noise. 

These  four  main  electrical  effects  cause  folio-wing 
malfunctions  because  of  its  direct  effect  on  radar 
performance  during  target  seaking,  finding,  locking 
and  firing  phases  of  an  aircraft. 

Transmission  Efficiency  Loss:  Transmission 
efficiency  loss  is  the  ratio  of  power  of  outgoing 
radar  beam  from  radome  wall  to  power  of  incoming 
radar  beam  to  radome  wall  and  it  is  given  as 
percents. 


Pout 

^^transmission  =  — 

Pu, 


Where ; 

Pout :  Power  of  outgoing  radar  beam  from  radome 
wall 

Pin  :  Power  of  incoming  radar  beam  to  radom  wall, 
octransmission  ^  Transiuission  efficiency  loss 

Existance  of  radome  infront  of  antenna  causes 
transmission  efficiency  loss  and  it  decreases  the 
range  of  wave.  This  decreases  effective  sense  range 
of  aircraft  radar. 

Effects  Of  Boresight  Error  : 

Boresight  error  is  defined  as  the  difference  between 
actual  sight  angle  and  fictitious  sight  angle  of  an 
object.  An  electromagnetic  wave  being  transmitted 
through  a  media  can  be  subject  to  reflections  and 
refractions  through  another  media. 
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Figure.6.:  Diffiision  electromagnetic  wave  from 
radome  material. 

If  the  electromagnetic  wave  comes  to  the  obsen'er 
eye  with  second  media  angle  (as  it  is  seen  from 
Figure  6)  the  observer  sees  the  wave  with  that  angle 
and  boresight  error  occurs.  Boresight  error  is 
defined  by  the  following  formula  : 

Gh  =A  seen  -  A  actual  (3) 

Where ; 

Gh  :  Boresight  error 
Aactual;  Actual  sight  angle  of  object 
Aseen  Aiigle  tlirougli  which  the  object  is  seen 
Boresight  error  is  an  angular  value  and  its  unit  is 
“radian”. But  since  radian  is  excessive  for  boresight 
miliradian  (mR)  is  used  instead.  Position  of  the 
target  is  determined  by  radar  antenna  by  means  of 
sending  the  wave  to  the  target  and  sensing  the 
reflected  w'ave  from  target.  If  the  boresight  error 
exceeds  the  limits  (4  mR)  the  error  affects  the 
operation  negatively.  This  situation  is  shovMi  in 
figure.7. 


Firing  distance:  L 


Figure.?.:  Formation  of  boresight  error 


From  Figure-7  ; 


Effects  Of  Distortion  In  Antenna  Diagram 

A  three  axis  measurement  media  \vith  a  shape  of 
lobe  exists  in  the  front,  side  and  rear  areas  of  the 
antenna  in  case  of  no  obstacle  in  front  of  antenna 
(no  radome  ).  During  radome  tests,  distortion  rate 
of  antenna  pattern  is  determined  by  observing  the 
size  of  main  lobe  peak  point.  If  the  reduction  in  size 
of  subject  peak  point  is  in  limits,  this  means  result 
of  the  test  is  positive. 

4.  Experimental  Analysis  Of  Effect  Of  Radome 
Stnictural  Anomalies  to  Antenna  Performance 

During  manufacturing  of  radomme  wall,  if  the 
density  of  resin  and  fiberglass  cannot  be  maintained 
the  same  at  every  point  in  the  structure  hoinogenity 
of  the  material  is  destroyed  and  thickness  of  the 
wall  changes  from  point  to  point.  These  are  called 
as  “stmctural  anomalies”  of  radome. 

4.1.  Experimental  Study 

In  this  experimental  study,  an  artificial  anomaly 
has  been  introduced  to  the  radome  and  boresight 
error  measurement  has  been  achieved.  Then  this 
anomaly  has  been  removed  and  boresight  error  has 
been  measured  again.  Consequently  difference 
between  both  error  values  has  been  calculated  and 
interpreted. 

During  the  experiment  a  “mica  plate”  with  size  of 
lOcmXlOcm  and  with  a  thickness  of  2  mm  has 

been  used  in  order  to  set  up  the  anomaly.  (Si=  6). 

Measurement  System,  Antenna  and  Test 
Equipment  Used  In  The  Experiment 

Antenna  and  radome  used  in  the  measurements 
have  been  located  in  the  same  position  used  in  the 
aircraft.  Equipments  used  in  the  measurements  are 
listed  below; 

AN/APQ-120  Test  Antenna 

CARGO  MODEL  B-350A-TU  System 

HP-8757C  Netw'ork  Analyzer 

HP- 1 1664 A  Detector 

HP-438A  Powermeter 

HP-8484A  Detector 

HP-8473D  Detector 

Mechanical  Adapters 

Other  auxilliarv'  equipment 


Xh 

taiiG  =  (4) 

L 

By  utilizing  above  formula  boresight  error  is 
calculated. 

In  this  formula. 

Xh  :  Distance  between  the  actual  and  fictituous 
position  of  target 
L  :  Firing  distance 

0  ;  Boresight  angle 


Experimental  Geometry: 
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Null  Seeker: 


Geometrical  position  of  the  null  seeker  on  which 
the  transciever  is  located  moves  in  X  and  Y  axis. 

Two  movement  has  been  given  to  radome.  These 
are; 

1.  45  degree  roll  angles  in  CW  direction  -45  and  - 
90  degrees  roll  angles  in  CCW  direction  have  been 
given  to  Z  axis  which  is  called  ROLL  axis. 

2.  (0)  -  (-60)  degrees  azimuth  traverse  has  been 
achieved  in  x  axis,  (movement  of  radome  parallel  to 
the  ground). 

3.  Frequency  :  8.795  GHz 

4.  Power  :  Approximately  0.260  pW 

EXPERIMENT  1 

Boresight  error  and  transmission  effectiveness 
measurements  have  been  achieved  and  their  graphs 
have  been  obtained  using  radome  without 
anomalies.  Then,  boresight  error  according  to  block 
diagram  given  in  figure.  10  and  transmission 
effectiveness  according  to  figure.  9  measurements 
have  been  achieved  using  radome  with  anomalies, 
(figure. 8.) 


Figure.9.:  Transmission  test  block  diagram 


Figure.l0.:  Boresight  error  measurement  block 
diagram 


In  the  first  experiment  anomaly  plate  has  been 
attached  to  the  radome  with  a  roll  angle  of  45°  and 
an  azimuth  angle  of  0°  to  12°.  Boresight  error 
measurement  results  have  been  compared  and  a 
difference  graph  has  been  obtained  (figure  11). 


Figure.8.:  Position  of  the  anomalies  on  the  radome 
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Figure.ll.:  Boresight  error  difference  graph 

It  is  seen  from  the  above  graph  that  anomaly 
produces  maximum  3.5  mR  boresight  error  through 
X  axis  between  0°  to  18°  azimuth  angle  range. 
Between  18°  to  60°  azimuth  azimuth  angle  range, 
there  is  no '  significant  change.  Through  Y  axis, 
since  normal  and  anomaly  graph  characteristics 
remain  nearly  same  no  excessive  peak  points  are 
observed.  Maximum  difference  occurs  at  8° 
azimuth  angle  which  corresponds  to  max  0.8  mR. 


TRANSMISSION  (%) 


•  4  «  12  16  21  24  26  32  3i  4»  44  46  52  56  6# 

AZIMUTH  (WEG) 


effectiveness  through  whole  area  inspite  of  the  fact 
that  anomaly  plate  has  been  located  between 
0°-  18°. 

As  a  result,  it  has  been  determined  that  the  anomaly 
plate  located  between  0°-18°  azimuth  angle  at  45° 
roll  angle  of  radome  affects  the  boresight  error 
excessively,  besides  it  causes  a  reduction  at 
transmission  effectiveness. 

EXPERIMENT  2 

In  this  experiment  anomaly  plate  has  been  attached 
between  20°  to  32°  azimuth  angle  at  -45°  radome 
roll  angle  (Figure  14).  Boresight  error  and 
transmission  effectiveness  measurements  have  been 
achieved  with  anomaly  and  without  anomaly  and 
relevant  graphs  have  been  drawn. 


Figure.  14.:  Position  of  anomaly  on  radome 

If  boresight  error  difference  graph  (Figure  15)  is 
investigated,  it  can  be  seen  that  -2.8  mR  at  15° 
azimuth  angle  and  3.15  mR  at  42°  azimuth  angle 
boresight  error  difference  values  through  X  axis 
have  been  obtained.  There  is  no  significant  change 
through  Y  axis. 


Figure.  12.:  Transmission  measurement  with 

anomaly 


TRANSMISSION  («/.) 
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F-4E  RADOME  TEST 

f^ORACAL-ANOMALY  TEST DlFFSEmCB  GRAPH 


2ND  TEST  ANOMALY  AT  20  DEGREE  AZIMUTH 


Figure.  15.  :Boresight  error  difference  graph 


Figure.  13.:  Normal  transmission  measurement 

If  transmission  effectiveness  measurement  graphs 
with  anomaly  and  -without  anomaly  (Figure  12  and 
13)  are  investigated,  it  is  seen  that  there  is  an 
average  reduction  of  6%  at  transmission 


If  transmission  effectiveness  measurement  graphs 
vith  anomaly  (figure.  17)  and  ivithout  anomaly 
(figure.  16)  are  investigated,  it  is  seen  that  anomaly 
produces  an  average  reduction  of  5%  through  whole 
azimuth  range. 
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Figure.l6.:  Graphs  without  anomaly 
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Figure.  17.:  Graphs  with  anomaly 

As  a  result,  it  has  been  determined  that  the  anomaly 
plate  located  between  20°  to  32°  azimuth  angle 
at 

-45°  radome  roll  angle  affects  the  boresight  error 
excessively,  besides  it  causes  a  reduction  at 
transmission  effectiveness. 

EXPERIMENT  3 


In  this  experiment  anomaly  plate  has  been  attached 
between  30°  to  42°  azimuth  angle  at  90°  radome 
roll  angle  (figure  18) 


Figure.  18.:  Position  of  anomaly  on  radome 


Since  previous  experiments  have  revealed  that 
major  effect  of  anomaly  plate  is  on  boresight  error 
rather  than  transmission  effectiveness  only 
boresight  error  measurements  have  been  achieved 
in  this  experiment. 

F-4E RADOME  TEST 


NORMAL-AT/OUALY  TEST  DIFFERENCE  GRAPH 

••RESlGHT(mm 


•  4  t  12  1ft  21  24  21  32  3ft  4|  44  4<  52  56  ft* 


AZIMUTH  (iEG) 

|— X  AXIS  —Yams  J 

JRDTEjrr  ANOMALYAT30DE(^^A2DvtUTH 

Figure.  19.:  Difference  graph 

If  boresight  error  difference  graph  (figure  19)  is 
investigated,  it  can  be  seen  that  maximum  value  of 
boresight  error  difference  through  X  axis  has  been 
obtained  as  3.2  mR  at  56°  azimuth  angle.  There  is 
no  significant  change  through  Y  axis.  This 
experiment  has  revealed  that  anomaly  plate  located 
between  30°  to  42°  azimuth  angle  at  90°  radome 
roll  angle  affects  the  boresight  error  excessively. 

CONCLUSIONS 

Ideal  radome  stnictures  are  transparent 
electromagnetically.  Besides  ideal  radome  materials 
react  to  all  wavelengths  the  same  as  they  react  to 
free  space  wavelength  electromagnetically. 
Radomes  are  subject  to  critical  aerodynamic  load, 
temperature,  rain  and  wind  errosion.  During  design 
of  a  radome  an  optimization  should  be  done  in 
order  to  meet  the  mechanical  requirements  as  well 
as  the  electromagnetic  requirements.  High  density 
materials,  such  as  alumina  and  ceramics  are  used 
for  heat  resistance.  Radome  anomalies  caused  by 
density  and  thickness  variations  in  the  radome 
structure  affect  the  electromagnetic  transparancy. 
Besides  they  affect  the  performance  of  the  antenna 
located  in  radome.  In  order  to  observe  these  effects 
in  details  artificial  anomalies  have  been  introduced 
to  the  radome  of  an  F-4E  a/c  and  transmission  and 
boresight  error  measurement  graphs  have  been 
drawn.  The  analysis  of  these  graphs  revealed  that 
radome  transmission  effectiveness  reduces  at 
anomaly  area.  This  decreases  the  sensing  capability 
of  the  a/c  which  means  sensing  range  decreases. 
Another  negative  effect  is  the  increase  at  boresight 
error.  This  means  the  a/c  senses  the  target  shifted 
from  its  actual  location.  This  is  a  vital  effect  which 
decreases  the  shooting  capabiliy  of  the  aircraft. 
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1  SUMMARY 

This  paper  introduces  the  Capricornio  Programme  by 
means  of  describing  the  vehicle  requirements, 
architecture  and  guidance  philosophy  as  well  as  the 
required  ground  facilities.  Later  and  in  a  more 
detailed  way,  Requirements  Specifications  and  Top- 
Level  Design  of  CAPRICORNIO  Launcher  Software 
are  presented,  with  a  reference  to  the  static  and 
dynamic  behaviour  of  the  chosen  architecture. 
Hardware  interaction  aspects  are  omitted.  Regarding 
the  Ground  Control  Computer  Software,  an  overview 
of  the  Rapid  Prototyping  Technique  through 
Lab  VIEW®  is  presented  with  a  look  to  the  first 
results.  This  article  shows  how  a  low  cost  software  is 
being  developed  with  a  high  modularity  and  flexibility 
degree  allowing  an  easy  migration  among 
demonstrator  vehicles  (ARGO)  and  finally,  the 
CAPRICORNIO  launcher. 


2  LIST  OF  SYMBOLS  AND  ACRONYMS 


t 

time 

0 

pitch  angle 

V 

yaw  angle 

X' 

horizontal  speed  within  the  trajectory 
plane 

z 

vertical  coordinate 

Z' 

vertical  speed 

ARTK 

Alsys®  Real-Time  Kernel 

BIT 

Built-In  Test 

CCM 

Communication  Control  Module 

GCC 

Ground  Control  Computer 

I/O 

Input/Output 

INS 

Inertial  Navigation  System 

INTA 

Institute  Nacional  de  Tecnica  Aeroespacial 

MPCC 

Multi-Protocol  Communication  Controller 

OBC 

On-Board  Computer 

TC 

Telecommand 

TM 

Telemetry 

TVA 

Thrust  Vector  Actuator 

TVC 

Thrust  Vector  Control 

A 


Figure  1:  ARGO  and  CAPRICORNIO  vehicles 
3  INTRODUCTION 

After  a  remarkable  experience  in  the  field  of  weapon 
and  sounding  rocket  [1]  [2],  in  1989,  INTA  began 
studies  on  the  feasibility  of  a  Spanish  micro-satellite 
launcher:  the  CAPRICORNIO  vehicle  [3]. 

The  objective  of  the  Capricornio  Programme  is  the 
development  of  a  launch  vehicle  capable  of  injecting 
micro-satellites  (up  to  100  kg)  into  a  low  orbit  (600 
km).  In  addition  to  this  objective,  the  programme 
aims  to  promote  the  capability  of  INTA  and  Spanish 
industry  in  both  the  design  and  integration  of  this 
kind  of  vehicles,  as  well  as  in  the  technologies 
involved.  The  vehicle  will  consist  of  three  solid 
propellant  stages,  with  a  total  mass  of  15  tons  and  an 
18  m  length. 

Basic  requirements  for  the  vehicle  were  divided  in  two 
classes  [4]: 

Primary: 

-  satellites  weight:  50-100  kg 

-  orbit:  600  km,  circular 

-  launching  point:  Spanish  territory  (Huelva  coast  or 
Canary  Islands) 

Secondary: 

-  postdeveloping  possibilities 

-  as  high  national  participation  as  possible. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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The  vehicle  was  called  Capricornio  (Figure  1)  and  its 
configuration  was  established  as  follows: 

-  Total  weight:  15000  kg 

-  Total  length:  18  m 

1st  stage  : 

•  motor:  CASTOR  IVB  (Thiokol  corporation) 

•  TVC  (Thrust  Vector  Control) 

•  aerodynamic  controls  to  limit  roll  rate 

2nd  stage: 

•  motor:  DENEB  (new  development) 

•  TVC  (pitch  and  yaw) 

•  cold  gas  thrusters  (roll) 

3rd  stage: 

•  motor:  MIZAR  (new  development) 

•  cold  gas  thrusters  (pitch,  yaw  and  roll) 

Prior  to  Capricornio  development,  INTA  began  in 
1993  the  development  of  ARGO,  whose  first  prototype 
will  fly  late  1996,  a  demonstrative  vehicle  to  develop 
and  test  DENEB  and  MIZAR  motors  and  as  many 
Capricornio  components  as  possible.  ARGO 
configuration  is  as  follows: 

-  Total  weight:  3900  kg 

-  Total  length:  9  m 

1st  stage  : 

•  motor:  DENEB  (without  TVC) 

•  aerodynamic  controls  (roll) 

2nd  stage: 

•  motor:  MIZAR 

•  TVC  (pitch  and  yaw) 

•  cold  gas  thrusters  (roll) 


exactness  of  the  rocket  motor  model  related  to  thrust 
and  combustion  time. 

As  the  characteristic  frequency  of  TVC  is  5  Hz, 
control  frequency  has  been  fixed  on  25  Hz.  Functions 
performed  every  computation  cycle  are  (Figure  2): 

*  get  t,  0,  Z,  X'  and  Z',  both  current  and  nominal. 
Nominal  data  are  stored  with  an  interval  of  1 
second.  An  interpolation  between  two 
consecutive  records  is  necessary  (Figure  3). 
Current  data  (navigation)  are  to  be  supplied  by  a 
strapdown  INS  (Inertial  Navigation  System). 

*  calculate  commanded  0  and  \|/  as  linear 
functions  of  the  deviations  of  the  former 
trajectory  parameters  (guidance). 

*  calculate  nozzle  deflections  by  implementing  a 
proportional/derivative  control,  as  linear 
functions  of  the  deviations  between  current  and 
commanded  angles  and  rates. 


t 

0 

Z 

X' 

Z' 

.01 

.339664 

26563.780 

399.164 

1128.928 

1.01 

.342213 

27685.590 

397.656 

1115.042 

2.01 

.343804 

28815.690 

411.949 

1145.415 

3.01 

.344376 

29976.950 

426.851 

1177.370 

4.01 

.344580 

31170.950 

442.326 

1210.880 

S.Ol 

.344651 

32399.230 

458.355 

1245.921 

6.01 

.344676 

33663.300 

474.931 

1232.484 

7.01 

.344685 

34964.680 

492.045 

1320.551 

8.01 

.344688 

36304.860 

509.693 

1360.109 

9.01 

.344688 

37685.360 

527.870 

1401.153 

10.01 

.344688 

39107.660 

546.580 

1443.682 

11.01 

.344688 

40573.240 

565.822 

1487.702 

Figure  3:  Nominal  trajectory  records 


Guidance  Philosophy 

The  guidance  algorithm  is  conceived  as  an  attitude 
guidance  where  the  vehicle  is  requested  to  follow  a 
pre-programmed  nominal  (plane)  trajectory.  The 
objective  is  to  reach  the  proper  attitude  and  velocity  at 
the  apogee.  Guidance  is  only  possible  during  those 
stages  where  TVC  is  present.  Provided  these  rocket 
motors  have  no  means  to  cut  combustion,  accuracy  is 
greatly  affected  by  external  disturbances  and  the 
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A  complete  system 

The  Programme  aims  to  develop  both  the  vehicles  and 
the  facilities  needed  to  operate  them.  They  conform 
the  system  depicted  in  the  Figure  4  which  consists  of: 

-  Ground  Control  Centre  with  the  following 
functionalities: 

*  Safety 

*  Operation 

*  Mission 

*  Testing 

*  Firing  switching 

*  TM  (Telemetry)  acquisition 

-  Block  House  consisting  of  the  GCC  (Ground 
Control  Computer)  and  a  firing  system. 

-  ARGO  vehicle  in  which  the  On-board  computer 
and  communications  control  boards  are  placed. 

-  Communication  umbilicals,  dedicated  lines  and 
power  lines. 


Figure  2:  Guidance,  Navigation  and  Control 


Figure  4:  Launching  place  schema 


4  AVIONICS 

Avionics  design  uses  specially  developed  integrated  - 
systems  with  the  accent  on  state  of  the  art  technology, 
a  high  level  of  integration,  flexibility  and  adaptability 
to  the  various  mission  requirements,  minimum  mass 
and  low  cost  of  test  and  launch  support. 

The  main  element  is  the  OBC  (On-board  Computer, 
Figure  5).  It  consists  of  two  boards,  CPU-40  and 
MPCC-1  (Multiprotocol  Communication  Controller), 
linked  by  a  VME  bus.  Specific  boards  are  PMV  68 
CPU-40  and  PMV  68  MPCC-1,  both  Military 
Conduction  Cooled  model,  from  Radstone 
Technology®  PLC,  based  on  Motorola®  68040  and 
68020  respectively. 

CPU-40  is  the  main  processor  unit,  with  a  25  Mhz  32 
bits  processor,  two  RS-423  channels  and  a  SRAM, 
FLASH  and  EEPROM  memory  configuration  that 
makes  'In  System  Programming’  feasible,  for  mission 
specific  parameters. 

MPCC-1  is  devoted  to  managing  communications 
within  the  vehicle,  discharging  CPU-40  of  these  tasks. 
It  provides  4  RS-422  synchronous/asynchronous 
(configurable)  full  duplex  channels,  and  is  able  to 
transmit  up  to  500  Kbits/s  in  all  four  channels 
simultaneously. 


One  of  the  channels  links  the  INS,  reading  HDLC 
data  frames  at  100  Hz,  with  a  rate  of  460.8  Kbits/s. 
INS  model  is  SAGEM  AGYLE  SP-10. 

Another  channel  links  the  telemetry  transmitter  (TM). 
This  is  the  most  stressed  link,  as  it  has  the  larger 
amount  of  data,  sum  of  the  remaining  links. 

The  last  used  channel  (4th  one  is  spare)  connects  all 
vehicle  actuators  and  transducers  through  a 
multipoint  line.  Each  secondary  station  consists  of  a 
CCM  (Communication  Control  Module),  an  INTA 
Avionics  Department  development  based  on  a 
Motorola®  68302,  which  includes  both  processor  and 
communication  control,  mounted  over  a  single- 
Europe  size  board  configuring  a  multi-purpose 
communication  and  data  acquisition  computer  to 
which  another  single-Europe  size  board  with  the 
required  analog  and  digital  I/O  (Input/Output)  is 
plugged. 

There  are  several  CCMs  along  the  vehicle,  each  one 
dealing  with  several  actuators  and  transducers.  Eor 
example,  ARGO  CCM-1  is  in  charge  of  distributing 
commands  to  the  ailerons  and  collecting  several 
different  data:  aileron  position,  aileron  temperature, 
DENEB  chamber  pressure  and  nozzle  temperature. 

There  are  only  two  commands  which  are  not 
processed  by  OBC:  1st  stage  firing,  which  is  wired  to 
a  switch  box  within  the  Block-House,  and  the 
destruction  system,  which  is  telecommanded  from  the 
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ground  facility.  Additionally,  high  sampling 
frequency  data  are  not  processed  by  OBC  but  directly 
packed  and  sent  with  the  remaining  telemetry  data. 

Communications  along  the  vehicle  are  HDLC  coded 
giving  high  reliable  links  and  allowing  an  easy 
connection  to  current  computer  networks.  This  is  a 
useful  feature,  specially  during  development.  The 
multipoint  vehicle  data  line  uses,  as  stated  above,  an 
RS-422  interface.  This  configuration  allows  each 
CCM  to  be  individually  connected  to  a  COM  port  of  a 
standard  PC  and  be  checked  out  with  a  dedicated 
software  prior  to  integration. 

On-board  communication  timing  is  based  on  a  100  Hz 
signal  provided  by  the  INS  directly  to  the  CPU-40 
board  which  produces  the  25  Hz  communication 
signal  that  synchronizes  CCMs  to  sample  and 
transmit  data. 


Figure  5:  Avionics  Architecture 


5  SW  DEVELOPMENT  METHODOLOGY 

Characteristics  of  the  avionics  software  programs 

The  on-board  computers  are  the  cornerstone  of  the 
avionics  systems  whose  development  spans  nearly  a 
decade.  The  avionics  software  offers  the  following 
main  characteristics: 

•  an  incremental  development;  it  is  indeed 

impossible  to  wait  until  the  definition  of  the  entire 
system  is  completed  to  initiate  the  software 
development. 

•  a  capability  to  implement  evolutions:  the 

development  and  generation  of  avionics  system 
and  their  associated  components,  give  rise  to 
requests  for  changes  concerning  the  software 
specifications.  Throughout  the  launcher 

operational  life,  corrective  and  upgrading 

maintenance  must  be  affordable  within  very  short 
time  periods. 

•  very  demanding  technical  requirements  (  real¬ 
time  constraints):  the  avionics  software  programs 


are  subjected  to  stringent  real-time  requirements 
(reaction  time  imposed  amounting  to  a  few 
milliseconds)  and  also  severe  quality  requirements 
(dependability,  efficiency,  sturdiness,  safety, 
reliability,...) 

•  economic  efficiency;  the  open-endedness  and 
reusability  of  software  components  have  become 
critical  criteria  for  the  development  of  avionics 
software  programs.  In  addition,  the  rapid  evolution 
of  hardware  technologies  has  led  to  the 
emergence  of  a  portability  requirement  designed  to 
make  the  software  programs  as  independent  as 
possible  from  the  processors  and  the  computer 
architecture. 


Software  development  methodology 

For  the  development  of  all  the  software  in  the 
CAPRICORNIO  programme,  INTA’s  own 
methodology  has  been  chosen.  This  methodology  is 
based  on  the  European  Space  Agency  software 
development  standards. 

Initially,  a  simple  “V”  software  life  cycle  was 
envisaged,  but  the  experimental  and  volatile  nature  of 
some  requirements  made  us  change  to  an  incremental 
development  life  cycle  (Figure  6).  Each  step  of  the 
incremental  model  contains  significant  variations 
with  regard  to  the  previous  one  on  the  mission 
characteristics:  number  of  stages,  stages  attributes 
(such  as  duration,  events  detected,  actions  to  be 
performed,  actuators  to  be  controlled,...)  payloads, 
apogee,  etc.  The  software  design  should  allow  an  easy 
adaptation  to  the  next  increment  with  the  minimum 
effort.  In  order  to  achieve  this  target,  the  architecture 
shall  have  a  high  degree  of  modularity. 


Figure  6:  Incremental  delivery  approach 


For  the  GCC  software  a  rapid  prototyping  approach 
was  selected  in  order  to  froze  the  user  interface 
requirements  as  soon  as  possible.  The  prototype  layout 
is  depicted  in  Figure  13. 
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The  Software  Requirements  phase 

In  the  Software  Requirements  definition  phase,  the 
developers  construct  an  implementation  independent 
model  of  what  is  requested  by  the  users.  This  model 
is  called  logical  model  and  represents  the  functional 
decomposition  of  the  system.  To  build  the  logical 
model,  a  Yourdon-DeMarco  Structured  Analysis 
with  a  real-time  extension  approach  has  been  used: 
Ward  &  Mellor  [6] 

In  the  Ward  &  Mellor  approach,  the  model  consists  of 
two  parts:  a  model  which  focuses  on  defining  what  the 
system  must  interact  with,  and  a  model  which 
describes  the  required  behaviour  of  the  system.  Both 
models  are  implementation  free. 

•  The  Environmental  model  is  a  description  of  the 
environment  in  which  the  system  operates.  This 
model  has  two  pieces: 

-  the  Context  Diagram  which  describes  the 
boundary  that  separates  the  system  from  the 
environment. 

-  the  Events  List  that  occur  in  the  environment 
to  which  the  system  must  respond. 

•  The  Behavioural  model  is  a  description  of  the 
required  behaviour  of  the  system.  This  model  has 
also  two  pieces: 

-  the  Transformation  Schema:  graphic 
representation  of  the  processes. 

-  the  Data  Schema  to  define  the  information 
within  the  system. 

The  Architectural  Design  phase 

In  the  Architectural  design  phase,  the  developers 
define  a  collection  of  software  components  and  their 
interfaces  to  establish  a  framework  for  developing  the 
software.  To  construct  the  software  architecture  a 
formal  method  based  on  the  Buhr  diagramming 
technics  has  been  used.  The  software  is  decomposed 
into  a  hierarchy  of  components  according  to  the  top- 
down  Buhr  approach. 

The  programming  language 

To  implement  the  on-board  software  the  Ada 
language  has  been  selected,  taking  into  account  its 
modularity  to  define  a  strong  software  structure. 


6  DEVELOPMENT  ENVIRONMENT 

In  order  to  manage  a  complex  software  development, 
the  Software  Development  team  uses  the  following  set 
of  tools: 

-  Specification  Tool:  StP® 


-  Design  Tool;  Popkin®  SA,  Lab  VIEW® 

-  Coding:  Alsys®  Ada,  LabVIEW®  and 
Watcom®  C 

-  Test;  LDRA  TestBed® 

-  Configuration  Management:  CVS,  RCS.  These 
tools  ensure  the  coherence  and  sharing  of 
software  components. 

-  Simulators:  Microsoft®  Visual  C+-)-,  Lab- 
Windows®  libraries. 

The  hardware  development  environment  is  depicted 
in  Figure  7.  It  consists  of: 

-  Host:  Sun®  SPARCstation  20  for  OBC 
software  development. 

-  PC  486  for  GCC  software  development. 

-  Development  Rack  which  contains: 

*  the  CPU40:  target  development  board, 

*  the  MPCC-1:  communications  development 
board  and 

*  the  ENET-P.  ethernet  connection  board. 


The  Real-Time  System 

To  develop  the  Real-Time  executive,  the  executive 
provided  with  the  Alsys®  Ada  compiler  will  be  used. 
This  consists  of  a  specific  real-time  kernel  (Alsys® 
Real  Time  Kernel,  ARTK)  that  provides  low-level 
services  that  can  not  be  expressed  efficiently  in  Ada. 


HOST 


Figure  7  :  Hardware  development  environment 


7  ON-BOARD  COMPUTER 

On-board  systems  are  characterised  by  a  large  number 
of  I/O  operations.  A  large  part  of  the  I/O  processing 
management  is  implemented  in  the  MPCC-1  board  in 
order  to  avoid  the  main  board  (CPU40)  overhead. 
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The  CPU40  board  is  in  charge  of  driving  the  vehicle 
throughout  its  operational  life  by  means  of  the  On¬ 
board  SW  subsystem. 

Software  Requirements  definition 

SE_ARGO  stands  for  “Software  Embarcado  • 
ARGO”  which  means  “ARGO  On-board  SW”  and 
will  support  the  following  functionalities  [7]: 

•  System  monitoring  using  the  status  data  provided 
by  the  sensors  located  in  the  subsystems  of  the 
vehicle.  Functions  available  will  be: 

-  to  initialize  and  check  subsystems  during  the 
prelaunch  phase 

-  to  check  all  the  alarms  during  flight 

•  Guidance  and  Control:  to  execute  the  guidance 
routines  and  generate  the  commands  to  be  sent  to 
the  actuators  placed  on  each  stage  in  order  to 
follow  the  nominal  trajectory  and  to  keep  the 
vehicle  stable. 

•  Mission  management,  to  execute  the  actions  to 
achieve  the  mission  objectives.  These  actions  will 
be  events  or  fault  driven  and  will  allow  the 
configuration  changes  of  the  launcher  during 
flight  (staging,  engine  firing...).  Therefore,  they 
will  be  responsible  for  the  software  mode  changes. 

•  FO  services.  Functions  available  will  be: 

-  to  provide  the  communication  board  with  the 
SE_ARGO  available  telemetry  which  will 
contain  SE-ARGO  status,  CPU  health  status, 
guidance  and  control  commands,  mission 
commands,  etc. 

-  data  acquisition. 

•  Timing  control  services  for  software  timing 
constraints. 

The  behaviour  of  the  software  is  defined  using  a 
transition  states  diagram  ( 

Figure  8)  in  which  each  transition  is  performed 
taking  into  account  the  events  produced  during  the 
mission.  The  following  states  are  considered: 

-  ARGO  Off.  represents  the  state  in  which  the 
vehicle  is  placed  on  the  launching  pad  and  all  the 
equipments  are  ready  to  be  powered. 

-  Mission  cancelled  could  be  reached  if  the  GCC 
operator  requires  it. 

-  Initialization  represents  the  state  in  which  all  the 
equipments  will  be  initialized. 

-  Prelaunch  checks  to  perform  all  the  subsystem 
BITS  (Built-in  Tests)  required  by  the  GCC 
operator. 

-  During  the  Launch  state,  a  sampling  of  the 
umbilicals  and  firing  chamber  pressure  sensors 
will  be  performed  in  order  to  establish  if  the  firing 
has  been  produced. 


-  1st  stage  flight  in  which  only  the  roll  control  will 
be  performed. 

-  Interstage  flight  state  will  be  reached  when  the 
DENEB  engine  combustion  is  finished.  First  stage 
separation  will  be  commanded. 

-  Pre-ignition  2nd  stage  state  will  be  reached  when 
the  first  stage  separation  is  detected.  The  MIZAR 
engine  ignition  will  be  commanded. 

-  Once  the  ignition  is  detected  2nd  stage  flight  state 
will  be  reached.  Roll,  Pitch  and  Yaw  control  will 
be  performed. 

-  Captive  flight  state  will  be  reached  when  the 
MIZAR  engine  combustion  is  finished.  Second 
stage  separation  will  be  commanded. 

-  Ogive  aperture  state  will  be  reached  when  the 
second  stage  separation  is  detected.  Pointing 
manoeuvres  will  be  performed. 

-  Experimental  flight  represents  the  state  in  which 
the  aperture  has  been  successfully  performed. 
Pointing  manoeuvres  required  by  the  experiment 
will  be  performed. 

-  Final  flight  state  will  be  reached  when  the 
experiment  is  finished. 


Figure  8:  ARGO  transition  states  diagram 
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The  description  of  the  environment  in  which  the 
system  operates  is  depicted  in  the  Environmental 
model  (Figure  9).  The  logical  external  entities 
identified  are: 

-  INS  which  provides  the  ARGO  navigation  data 
and  receives  the  commands  needed  to  control  its 
functional  modes. 

-  GCC  sends  the  commands  to  perform  the 
prelaunch  tasks  and  receives  its  results. 

-  CLK.  The  clock  will  drive  the  behaviour  of  the 
system.  The  basic  functional  cycle  will  be  of  40 
ms.  Every  cycle,  guidance  and  control  routines 
will  be  executed  and  the  corresponding  commands 
will  be  sent,  mission  actions  will  be  commanded, 
check  activities  will  be  performed  and  the 
associated  Telemetry  will  be  sent  to  the 
communication  board. 

-  MPCC-1.  The  communication  board  provides  the 
status  information  of  all  the  vehicle  subsystems.  It 
accepts  the  commands  to  drive  the  launcher  and 
distributes  it  to  the  corresponding  subsystem. 


Figure  9:  Environmental  diagram 


The  Environmental  diagram  is  broken  down  into  a 
hierarchy  of  processes  which  conform  the 
Transformation  Schema.  A  summary  of  the  schema  is 
presented  in  Figure  10  in  which  two  levels  are 
depicted. 

‘ARGO  control”  is  broken  down  in  five  processes: 

1 .  Receive  vehicle  data,  shall  obtain  and  prepare  the 
vehicle  status  information. 

2.  Generate  command  is  in  charge  of  perform: 

-  flight  operations:  send  commands  to  drive  the 
vehicle  and  to  carry  out  the  in-flight  checking 
activities. 

-  prelaunch  operations:  send  commands  to 
initialize  subsystems  and  perform  the  on¬ 
ground  checks. 

3.  Build  frame,  is  in  charge  of  packing  the  TM  and 
TC  (TeleCommand)  frame. 

4.  Receive  ground  data,  during  the  prelaunch 
activities. 

5.  Generate  cycle  is  in  charge  of  providing  the 
timing  signal  for  synchronisation  purposes. 
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Figure  10:  Break  down  diagram 


Architectural  Design 


Following  the  results  obtained  during  the  analysis,  a 
set  of  SW  components  were  defined  [8].  The  top-level 
architecture  diagram  is  depicted  in  Figure  11.  The 
first  level  contains  a  set  of  encapsulated  packages 
which  export  services  or  data  structures  represented 
with  arrows  in  the  diagram.  These  packages  are 
subsequently  described; 

•  epu-main  will  contain  the  main  program,  the 
scheduler  and  the  watchdog  task  responsible  for 
the  surveillance  of  the  system.  A  cyclic  executive 
has  been  chosen  with  a  primary  curl  of  40  ms. 
duration.  Taking  into  account  the  current  mode,  a 
function  call  sequence  will  be  executed  in  order  to 
perform  the  mission  and  guidance  activities. 

•  the  timing  package,  is  in  charge  of  capturing  the 
tick  interruption  from  the  INS  and  provide  it  to  the 
watchdog  and  the  scheduler  for  tasks 
synchronisation. 

•  the  mission  library  contains  all  the  functions 
needed  to  generate  the  commands  to  be  sent  to  the 
mission  elements  (such  as  pyros)  in  order  to 
achieve  the  mission  objectives.  The  set  of 
functions  that  shall  be  executed  once  per  cycle, 
depends  on  the  current  operational  mode. 

•  the  guidance  library  contains  all  the  routines 
needed  to  generate  the  commands  to  be  sent  to  the 
actuators  in  order  to  guide  (following  the  nominal 
trajectory)  and  control  the  vehicle  during  the 
flight. 

•  the  checks  package  consists  of  two  sub-packages 
for  both  prelaunch  and  flight  testing. 

•  the  TC  package  contains  the  functions  needed  to 
pack  the  telecommands  generated  each  cycle.  It 
consists  of  two  sub-packages  for  both  GCC  and 
MPCC-I  TC. 

•  the  TM  package  contains  the  functions  needed  to 
pack  the  available  telemetry  each  cycle.  It  consists 
of  two  sub-packages  for  both  GCC  and  MPCC-1 
TM. 

•  the  mode  change  package  is  in  charge  of  deciding 
the  operational  mode  for  the  current  computation 
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cycle  taking  into  account  several  navigation  and 
other  vehicle  data  combinations. 

•  the  vehicle  data  package  is  the  main  data  storage. 
It  is  decomposed  into  four  sub-packages: 
OBC_data,  INS_data,  CCM_data  and  MPCC- 
l_data.  Each  one  consists  of  data  structures 
definition  and  its  handling  procedures. 

-  OBC_data.  Defines  several  data  types 
corresponding  to  the  different  mission  states 
depicted  in 

-  Figure  8.  It  contains  also  the  SW  and  HW 
status  and  all  the  timing  related  data. 

-  INS_data.  Specifies  the  navigation  TM  packet 
and  also  the  command  data  type  to  be  sent  to 
the  INS. 

-  CCMjdata  (MCC_data).  Specifies  the  CCMs 
TM  packet  (temperatures,  voltages,  battery 
status,  aileron  position,  TVA  (Thrust  Vector 
Actuator)  angle,  alarms,  engine  status,  etc.) 
and  also  the  command  data  type  to  be  sent  to 
each  one  (TVA,  engine  ignition,  stages 
separation,  etc.). 

-  MPCC-l_data.  Defines  the  data  types  handled 
by  the  MPCC-1:  CCMs  and  INS  status,  CCMs 
and  INS  validity  and  retransmitted  frames, 
CCMs  and  INS  communication  establishment 
commands,  etc. 

As  an  example,  the  MPCC-l_data  package  Ada 
specification  is  presented  in  Figure  12. 

•  the  I/O  package  contains  all  the  services  needed  to 
perform  the  I/O  operations  for  both  GCC  through 
the  umbilical  and  MPCC-1  through  the  VME  bus. 


Figure  11:  Top-level  architectural  design 


to  obtain  a  set  of  software  layers  or  increments  which 
can  run  autonomously. 


package  COMUNICACION_MPCCl  is 
25 


type  T_TM_MPCC1  is 
record 

ESTADO_COM_MCC_1 

3  0  TRAMA_VALI DA_MCC_1 

TRAMA_RETRAS_MCC_1 
ESTADO_COM_MCC_2 
‘TRAMA_VALrDA_MCC_2 
TRAMA_RETRAS_MCC_2 
35  ESTADO_COM_MCC_3 

TRAMA_VALIDA_MCC_3 
TRAMA_RETRAS_MCC_3 
ESTADO_COM_MCC_4 
TRAMA_VAL I DA„MCC_  4 
40  TRAMA_RETRAS_MCC_4 

ESTADO_COM_MCC_5 
TRAMA_VAL I DA_MCC_  5 
TRAMA_RETRAS_MCC_5 
ESTADO_COM_TRAS_TM 

4  5  TRAMA_VALI DA_TRAS_TM 

TRAMA_RETRAS_TRAS_TM 
ESTADO_COM_PI 
TRAMA_VALIDA_PI_1 
TRAMA_VALIDA_PI_2 
50  TRAMA_VALIDA_PI_3 

TRAMA_VAI.IDA_PI_4 
TRAMA_RETRAS_PI 
ESTADO_MPCCl 
end  record; 

55  for  T_TM_MPCC1  use 

record 

ESTADO_COM_MCC_l 
TRAMA_VALIDA_MCC_1 
TRAMA_RETRAS_MCC_1 
60  ESTADO_COM_MCC_2 

TRAMA_VAi:.IDA_MCC_2 
TRAMA_RETRAS_MCC_2 
ESTADO_COM_MCC_3 
TRAMA_VALIDA_MCC_3 
65  TRAMA_RETRAS_MCC_3 

ESTADO_COM_MCC_4 
TRAMA_VALIDA_MCC_4 
TRAMA_RETRAS_MCC_4 
ESTADO_COM_MCC_5 
7  0  TRAMA_VALIDA_MCC_5 

TRAMA_RETRAS_MCC_5 
ESTADO_COM_TRAS_TM 
TRAMA_VALIDA_TRAS_TM 
TRAMA_RETRAS_TRAS_TM 
75  ESTADO_COM_PI 

TRAMA_VALrDA_PI_l 
TRAMA_VALIDA_PI_2 
TRAMA_VA  L IDA_PI _3 
TRAMA_VALIDA_PI_4 
80  TRAMA_RETRAS_PI 

ESTADO_MPCCl 
end  record; 


TIPOS,T_SWITCH; 

T I PO  S . T_TRAMA_VA  LIDA; 
TIPOS.T_UINT6; 

TIPOS  .  T__SWITCH  ; 

TIPOS .T_TRAMA_VALIDA; 
TIPOS.T_UINT6; 

TIPOS. T_SWITCH; 

TIPOS . T_TRAMA_VALI DA ; 
TIPOS. T_UINT6; 
TIPOS.T_SWITCH; 

TI POS . T_TRAMA_VALT  DA ; 
TIPOS. T.UINTe.- 
TIPOS.T.SWITCH; 

TIPOS . T_TRAMA_VALIDA; 
TIPOS. T_UINT6; 

TIPOS. T_SWITCH; 

TIPOS . T_TRAMA_VALIDA; 
TIPOS. T_UINT6; 

TIPOS. T_SWITCH; 

TIPOS . T_TRAMA_VALIDA; 
TIPOS . T_TRAMA_VALIDA; 
TIPOS . T_TRAMA_VALIDA; 
TIPOS  .T.TRAMA.VALIDA.- 
TIPOS.T.UINTe; 

TIPOS. T_INT16; 


at  0 
at  0 
at  0 
at  1 
at  1 
at  1 
at.  2 
at  2 
at  2 
at  3 
at  3 
at  3 
at  4 
at  4 
at  4 
at  5 
at  5 
at  5 
at  6 
at  6 
at  6 
at  6 
at  6 
at  6 
at  6 


range  0. .0; 
range  1 . . 1 ; 
range  2 . . 7 ; 
range  0 . . 0; 
range  1 . . 1 ; 
range  2. .7; 
range  0 . . 0 ; 
range  1 . . 1 ; 
range  2 . . 7 ; 
range  0. .0; 
range  1 . . 1; 
range  2 . . 7 ; 
range  0 . . 0 ; 
range  1 . . 1 ; 
range  2. .1 ; 
range  0 . . 0; 
range  1 . . 1 ; 
range  2 . . 7 ; 
range  0 . .0; 
range  1 . . 1 ; 
range  2 . . 2 ; 
range  3 . . 3 ; 
range  4 . . 4 ; 
range  5 . . 10 ; 
range  11 .  . 26 ; 


75  bits 


85 


90 


95 


100 


105 


110 


115 


120 


type  T_TC_MPCC1  is 
record 

CMD_ACTIVAR_COM_MCC_l 
ACTIVAR_COM_MCC_l 
CMD_ACTIVAR_COM_MCC_2 
ACTIVAR_COM_MCC_2 
CMD_ACTIVAR_COM_MCC_3 
ACTIVAR_COM_MCC_3 
CMD_ACTrVAR_COM_MCC_4 
ACTIVAR_COM_MCC_4 
CMD_ACTIVAR_COM_MCC_5 
ACTIVAR_COM_MCC_5 
CMD_ACTIVAR_COM_PX 
ACTIVAR_COM_PI 
CMD_ACTIVAR_COM_TRAS_TM 
ACTIVAR_COM_TRAS_TM 
CMD_ACTIVAR_COM_MPCCl 
ACTIVAR_COM_MPCCl 
end  record; 
for  T_TC_MPCC1  use 


TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 

TIPOS 


T_COMANDO. 
T.SWITCH; 
T_COMANDO 
T_SWITCH; 
T_COMANDO 
T_SWITCH; 
T_COMANDO 
T_SWITCH; 
T_COMAKDO 
T_SWITCH; 
T_COMANDO 
T_SWITCH; 
T_COMANDO 
T_£WITCH; 
T.COMANDO 
T_ SWITCH; 


.VALIDO, 

.VALIDO. 

_VALIDO, 

.VALIDO 

.VALIDO 

.VALIDO 

.VALIDO 

.VALIDO 


CMD_ACTIVAR_COM_MCC_l  at  0 
ACTIVAR_COM_MCC_l  at  0 
CMD_ACTIVAR_COM_MCC_2  at  0 
ACTIVAR_C0M_MCC_2  at  0 
CMD_ACTIVAR_COM_MCC_3  at  0 
ACTIVAR_COM_MCC_3  at  0 
CMD_ACTIVAR_COM_MCC_4  at  0 
ACTIVAR_COM_MCC_4  at  0 
CMD_ACTIVAR_COM_MCC_5  at  1 
ACTIVAR_COM_MCC_5  at  1 
CMD_ACTIVAR_COM_PI  at  1 
ACTlVAR_COM_PI  at  1 
CMD_ACTIVAR_COM_TRAS_TM  at  1 
ACTIVAR_COM_TRAS_TM  at  1 
CMD_ACTIVAR_COM_MPCCl  at  1 
ACTIVAR  COM_MPCCl  at  1 


range  0 . . 0 
range  1 . . 1 
range  2 . . 2 
range  3 . . 3 
range  4 . . 4 
range  5 . . 5 
range  6 . . 6 
range  7 . . 7 
range  0 . . 0 
range  1 . . 1 
range  2 . . 2 
range  3 . . 3 
range  4 . . 4 
range  5 . . 5 
range  6 . . 6 
range  7 . . 7 


end  record; 


--  16  bits 


125 


procedure  INICIALIZAR_DATOS_MPCCl  ( 

TM_MPCC1  :  IN  OUT  T_TM_MPCC1; 
TC_MPCC1  :  IN  OUT  T_TC_MPCC1  ) ; 


130 


procedure 


INICIALIZAR_TC_MPCC1  ( 

TC_MPCC1  :  IN  OUT  T_TC_MPCC1  ) ; 


end  COMUNICACTON_MPCC1; 


Incremental  model 


Figure  12:  MPCC-l_data  package  specification 


The  objective  of  the  incremental  development  is  to 
obtain  the  most  important  functionalities  in  the  first 
phases  of  the  software  life  cycle,  while  the  secondary 
functionalities  are  implemented  later.  Software 
functionalities  are  stablished  into  a  hierarchy  of 
priorities  and  grouped  in  a  coherent  manner  in  order 


The  incremental  development  model  has  been 
stablished  in  the  following  terms; 

1st  step'. 

-  communication  between  GCC  and  CPU-40. 

-  communication  between  CPU-40  and  INS. 
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-  communication  between  CPU-40  and  MPCC-1 

-  vehicle  control  (staging,  MIZAR  ignition,  ogive 
separation)  under  normal  conditions. 

2nd  step  : 

-  roll  control  during  first  stage  flight. 

-  guidance  during  second  stage  flight. 

3rd  step  : 

-  cold  gas  thrusters  attitude  control  from  the  second 
stage  flight  till  the  end  of  the  mission. 

4th  step: 

-  INS  data  filter 

-  vehicle  control  under  abnormal  conditions 

8  GROUND  CONTROL  COMPUTER 

The  main  GCC  functions  are  [9]: 

•  Vehicle  Initialization  and  Pre-Launch  Tests.  GCC 

commands  initialization  of  Cold  Gas  system  and 
TV  A  by  opening  the  respective  tank  valves 

through  pyrotechnical  mechanisms.  It  also 
commands  alignment  and  navigation  start  of  INS, 
and  pre-launch  tests  of  TVC  and  ailerons. 

•  Provide  a  proper  operator  interface.  It  shows  the 
telemetry  data  in  a  clear  way  using  graphs,  gauges, 


tables,  etc.  to  make  them  easier  to  understand  and 
simplify  the  troubleshooting  procedures.  To  send  a 
command  the  user  has  to  press  simply  one  button. 
If  the  command  requires  some  parameters,  a 
dialog  box  appears  to  the  user  to  ask  the  values 
and  control  the  coherence  and  the  range  of  all 
parameters.  This  easy  way  of  controlling 
eliminates  any  error  from  the  operator  and  does 
not  require  complex  operations  or  additional 
hardware  to  be  used. 

•  Register  pre-launch  sessions.  Records  each 
received  data  frame  and  provides  tools  to  replay 
registered  sessions  in  order  to  review  problematic 
situations. 

•  Print  output.  Trace  major  events  in  a  paper  report. 

•  Integration  tests.  GCC  is  not  only  used  to  monitor 
vehicle  health  during  pre-launch  phase  but  also  to 
monitor  stages  health  prior  to  vehicle  assembling. 

The  adopted  solution  is  a  system  entirely  implemented 
using  the  graphic  development  tool  LabVIEW©  by 
National  Instruments™  on  a  PC  environment  running 
Microsoft®  Windows  3.11. 
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Figure  13:  GCC  software  prototype  layout 
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A  prototype  of  the  GCC  software  has  already  been 
done  (Figure  13)  and  evaluated  by  the  user  (Rocket 
Motors  Laboratory  personnel)  outstanding  the 
following  advantages  and  drawbacks: 

Advantages 

-  quick  development 

-  nice  looking  and  easy  to  reconfigure  interface 

-  easy  understanding  of  data 

-  easy  management  of  commands 

Drawbacks 

-  Limited  speed  performances.  It  was  not  easy  to 
deal  with  a  1 50  bytes  frame  at  25  Hz  and  a  rate  of 
38000  kbits/s,  provided  it  was  both  processed  and 
recorded.  However,  the  feeling  is  that  this  problem 
could  be  easily  solved  applying  several  strategies; 
increase  computer  power,  reduce  vehicle 
communications  frequency  during  pre-launch  or 
even  link  C  communication  routines  to  the 
Lab  VIEW®  application. 

-  Processing  algorithm  modifications  become 
harder  to  implement  as  the  application  grows. 

This  problem  is  highly  influenced  by  the 
Graphical  Programming  Language  of  LabVIEW® 
which  turned  out  to  be  much  less  flexible  than  a 
conventional  High  Order  language  written  by 
means  of  a  text  editor. 
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Signature  Avionics  - 

Signature  Optimised  Operating  of  a  Stealth  Aircraft 
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Military  Aircraft  Division  (LMT  3) 
81663  Munich 
Germany 


1  Summary 

Stealth  design  is  one  design  principle  for  next 
generation  combat  aircraft.  The  effort  in  this  area  have 
a  long  history  at  the  Daimler-Benz  Aerospace  (Dasa), 
formerly  MBB,  e.g.  the  Lampyridae  project  in  the 
early  80’s. 

Operational  studies  have  shown  that  the  introduction 
of  stealth  design  will  increase  the  survivability  of 
combat  aircraft  significantly,  especially  against 
airborne  threats.  Yet  the  effective  use  of  critical 
signatures  during  a  mission  and  the  matching  of  tactics 
to  stealth  features  require  the  development  of  an 
adapted  avionics. 

This  adapted  avionics  -  signature  avionics  -  will 

•  not  compromise  the  stealth  design, 

•  take  direct  advantage  from  the  stealth 

characteristics, 

•  and  utilise  the  stealth  properties  via  an  integrated 
tactical  mission  control. 

To  transform  this  idea  into  an  applicable  format  suited 
for  the  implementation  in  aircraft  avionics  systems 

•  a  functional  breakdown  in  individual  functions, 

•  prototyping  and  performance  analysis  of  these 
functions, 

turns  out  to  be  necessary. 

The  feasibility  of  this  approach  has  been  proven  on 
the  signature  avionics  function  „fly  by  signature"  as  an 
example. 

2  Introduction 

Low  observability  appears  as  one  of  the  prominent 
features  for  next  generation  combat  aircraft. 

Studies  at  the  military  division  of  Daimler-Benz 
Aerospace  (Dasa-LM)  -  as  well  as  elsewhere  -  prove 
the  operational  utility  of  stealth  designs.  However, 
these  studies  show  also  that  a  stealth  design  alone  is 
not  sufficient  to  protect  the  aircraft  in  a  hostile 
environment.  Low  observables  must  be  accompanied 
by  appropriate  avionics  -  "signature  avionics". 


Signature  avionics  refers  to  the  adaptation  both  of 
hardware  and  software.  The  multiple  interactions 
between  vehicle  and  avionics  systems  in  a  mission 
require  a  comprehensive  approach  with  many  aspects 
to  be  considered.  For  example,  uncontrolled 
electromagnetic  emissions  from  avionics  components 
(radar,  missile  approach  wamer,  etc.)  can  jeopardise 
the  advantages  gained  from  a  low  signature  design, 
but  mission  needs  must  be  fulfilled  and  appropriate 
tactics  should  reconcile  the  differing  objectives. 

The  realisation  of  signature  avionics  with  respect  to 
software  is  via  correlated  functions:  the  signature 
avionics  functions  (SAFs).  The  content  of  SAF  is 
determined  by  the  scenario,  its  threats  and  the 
aircraft  and  its  mission. 

Experimental  and  theoretical  methods  are  required  to 
analyse  the  complex  interrelations  between  stealth 
design  and  avionics.  In  this  paper  we  describe  how 
SAFs  are  developed,  analysed  and  evaluated  at  Dasa. 

The  paper  is  organised  into  5  further  chapters: 

•  Chapter  3  is  meant  to  motivate  the  issue. 

•  Chapter  4  discusses  signature  avionics  in  greater 
detail. 

•  Chapter  5  describes  tools  for  signature  avionics 
development  and  evaluation  at  Dasa. 

•  Chapter  6  elucidates  the  elements  and  the 
operation  of  the  SAF  „Fly  by  Signatue". 

•  Chapter  7  gives  a  short  resume. 

3  Motivation 

Stealth  design  concepts  have  a  long  history  at  Dasa, 
formerly  MBB.  An  example  is  the  Lampyridae  project 
for  a  stealth  fighter  in  the  early  80’s  paralleled  and 
followed  by  a  number  of  studies. 

Operationally  in  terms  of  survivability  and 
effectiveness  in  penetrating  missions  these  analyses 
show  that 

•  with  respect  to  ground  based  air-defence,  low 
flight  altitudes  dominate  low  radar  cross  section  in 
a  dense  threat  environment.  Terrain  masking  limits 
the  effect  of  signature  reduction  (see  figure  1),  but 
additional  benefits  can  be  envisioned  via  tactics 
adapted  to  the  signature  characteristics. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  "Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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•  even  a  very  low  radar  cross  section  (RCS)  does  not 
allow  for  a  safe  penetration  at  medium/high 
altitudes  on  its  own,  without  additional  measures. 

•  against  airborne  air  defence,  a  significant 
reduction  of  radar  cross  section  is  effective 
(however  improvable),  if  airborne  air  defence 
relies  on  active  radar  only  (see  figure  2). 

•  if  the  air  defence  side  exploits  on  other  signatures 
of  the  penetrating  aircraft,  low  radar  cross  sections 
may  be  compensated  for. 

The  spectrum  of  other  signatures  comprises 

•  the  infrared  signature, 

•  the  visual  signature, 

•  the  acoustic  signature, 

•  active  electromagnetic  emissions, 

•  inadvertent  electromagnetic  emissions. 

In  the  context  of  penetrating  missions  by  low  RCS 

vehicles  against  ground  based  and  airborne  defences 

these  signatures  may  be  qualified  as  follows: 

•  Except  for  high  altitudes  of  both  sensor  and  target 
and/or  high  target  speeds,  IR-sensor  ranges  remain 
in  the  order  of  magnitude  of  radar  ranges  in  frontal 
target  aspects. 

•  Visual  ranges  are  even  shorter. 

•  Due  to  the  dependence  of  the  sound  velocity  on 
the  atmospheric  conditions  it  is  difficult  to  use  the 
acoustic  signature  for  locating  the  target  timely 
and  precisely  enough  for  effective  counteractions. 

•  Active  electromagnetic  emissions,  e.g.  from  radar, 
altimeter,  missile  approach  wamer,  data  links, 
communications,  allow  for  long  range  all-weather 
detection  and  angular  measurements  and,  with 
already  existing  sensors,  can  re-establish  air 
defence  early  warning  coverage.  Moreover  the 
locating  capabilities  of  these  sensors  are  sufficient 
for  timely  alert  and  guidance  of  air  defence  assets. 
Accuracies  are  good  enough  to  direct  air  defence 
systems  up  to  the  point  where  they  can  use  their 
acquisition  and  fire  control  sensors. 

•  With  respect  to  inadvertent  electromagnetic 
emissions,  no  operational  sensors  are  known  to  us, 
but  efforts  to  counter  the  stealth  approach  can 
result  in  sensors  with  capabilities  comparable  to 
the  above. 

Therefore,  two  goals  rate  high  in  priority: 

•  denying  the  threat  the  use  of  critical  signatures 
during  the  mission 

•  drawing  additional  benefits  from  matching  tactics 
to  stealth  features. 


4  Signature  Avionics 

Referring  to  the  motivation  given  above,  there  will  be 
specific  requirements  to  the  avionics  systems  in  the 
case  of  a  stealth  design  of  the  aircraft.  Avionics 
components  and  subsystems  as  well  as  their  operation 
must  be  designed  to  meet  the  objectives: 

(1)  Avionics  that  do  not  to  compromise  the  stealth 
design  by; 

•  spoiling  the  RCS  signature 

•  active  electromagnetic  emissions 

(2)  Avionics  that  take  direct  advantage  of  the  aircraft's 
stealth  characteristic, 

(3)  Avionics  through  which  stealth  design  and 
avionics  functions  are  co-ordinated  by  integrated 
tactical  mission  control. 


Figure  1:  Aircraft  losses  due  to  ground  based  air 
defence 


Figure  2:  Aircraft  losses  due  to  airborne  air 
defence 


Without  attempting  completeness,  implications  are  as 
follows: 


We  believe  that  both  aims  can  be  achieved  by  the 
above  mentioned  signature  avionics  approach. 

To  achieve  these  objectives,  the  avionics  systems  have 
to  be  analysed  carefully  for  extensions  to  harmonise 
with  and  to  support  the  stealth  design  of  the  aircraft. 


(1)  Not  to  compromise  stealth  design 

Component  design  and  integration  (e.g.  sensor 
apertures,  internal  weapon  bay  and  its  operation  for 
weapon  release)  not  increasing  the  signatures  in 
critical  aspects;  operation  of  emitting  sensors 
controlled  in  time,  space,  energy,  waveform  in  the 
mission  context,  allowing  for  the  employment  of 
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active  sensors  only  if  indispensable,  e.g.  for  target 
acquisition  in  adverse  weather  conditions,  giving 
minimal  information  to  the  threat. 

(2 )  To  take  direct  advantage 

The  strong  anisotropy  of  the  radar  cross  section  of  a 
stealth  aircraft  offers  a  new  degree  of  freedom  that  can 
be  tactically  exploited  via  manoeuvring  e.g.  to  exhibit 
the  minimal  RCS  to  the  threat.  This  requires  the 
knowledge  of  the  aircraft  signature  and  of  the 
operation  and  lethality  of  the  hostile  weapon  systems. 

(3)  Integrated  tactical  mission  control 

New  tactical  concepts  and  mission  profiles  require  a 
tactical  mission  controller  for: 

•  information  gathering/sensor  operation 

•  situation  assessment  and  tactical  decision  making 

•  timing  of  transmissions 

•  routing/re-routing,  tactical  manoeuvring 

•  employment  of  ESM  and  ECM  systems 

Breaking  down  this  new  avionics  system  in  a 
functional  manner  leads  to  signature  avionics 
functions  (SAFs). 

Examples  are: 

•  information  management,  data  fusion  and  cueing 
for  passive  and  active  sensors  and  external 
sources. 

•  new  means  of  navigation,  e.g.  introduction  of  a  3D 
terrain  data  base  in  connection  with  GPS  (global 
positioning  system). 

•  emission  management,  i.e.  situational  emissions, 
power  management  by  spatial  and  temporal 
limitations  of  emissions. 

•  introduction  of  data  compression  and  spread 
spectrum  methods  concerning  communication, 

•  adaptive  camouflage. 

5  Development  and  Evaluation  of 
Signature  Avionics  Functions 

Figure  3  schematically  shows  how  signature  avionics 
functions  are  realised.  From  aircraft  characteristics, 
system  requirements  and  for  the  mission  scenario 
environment,  the  definition  of  SAFs  comprises 

•  prototyping  and  performance  analysis, 

•  software  (SW)  development, 

•  evaluation,  ranking  and  selection, 

resulting  in  new  software  modules,  requirements  for 
new  hardware  and  modifications  to  existing  software. 

Four  main  tasks  arise: 

•  Identification  and  specification  of  possible 
candidates  for  avionics  functions  necessary  for  the 
aircraft  to  utilise  its  stealth  properties. 

•  Development  of  the  identified  avionics  functions 
by  rapid  prototyping  to  create  software  modules 


that  can  be  integrated  in  a  simulated  or  real 
avionics  system. 

•  Test  and  evaluation  of  the  developed  software  with 
respect  to  operational  utility  and  compatibility 
with  other  avionics  subsystems. 

•  Ranking  of  the  different  signature  avionics 
functions  developed  and  selection  of  the  most 
promising  candidates. 

To  achieve  short  cycles  of  software  development  on 
the  one  side  and  to  check  the  compatibility  and 
performance  of  the  software  representing  the  SAF  on 
the  other  side,  the  development  environment  described 
in  the  following  chapters  has  been  set  up. 


Figure  3:  Objectives  for  the  development  of  SAFs 
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5.1  Development 

The  key  to  the  development  of  an  operational 
signature  avionics  subsystem  is  a  stepwise  approach 
setting  out  from  rapid  prototyping  on  workstations, 
transferring  to  ground  based  demonstrators,  increasing 
‘hardware  in-the-loop’  components  (including 
operational  software)  and  aiming  for  in-flight 
verification. 
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Rapid  prototyping  of  the  software  modules  is 
performed  in  the  Dasa  Software  Technology 
Environment  consisting  of  a  cluster  of  Symbolics  and 
Silicon  Graphics  workstations.  During  this 
development  of  the  software  modules,  existing 
models  of  terrain,  threats,  radar  signatures,  vehicles, 
etc.  are  used.  Initial  testing  of  the  software  modules 
with  respect  to  behaviour  and  numerical  stability  is 
also  performed  in  the  Software  Technology 
Environment. 

In  the  next  step  the  software  modules  representing  a 
specific  signature  avionics  function  are  integrated  in 
the  Avionics  Testbed,  shown  in  figure  4.  This 
Avionics  Testbed  consists  of  an  experimental  cockpit 
equipped  with 

•  various  display  and  interaction  capabilities. 

•  control  elements  like  stick,  pedals,  throttles. 

•  simulated  external  view. 

and  a  real-time  flight  control  system 

•  to  model  the  vehicle  manoeuvres. 

•  to  transform  pilot  inputs  into  steering  and  control 
values. 

•  to  provide  simulated  navigation  data. 

•  to  provide  autopilot  functions. 


Figure  4:  Avionics  Testbed 


Actually  the  Software  Technology  Environment  is 
linked  to  the  Avionics  Testbed  via  Ethernet.  In  this 
environment  the  interaction  of  signature  avionics 
functions  with  other  avionics  functions  and  the  man- 
machine  interface  can  be  studied. 

Optionally,  the  development  phase  can  be  rounded  off 
with  a  test  phase  in  a  flying  testbed,  e.g.  in  a  stealth 
aircraft  as  shown  in  figure  5. 

5.2  Evaluation 

Whereas  the  evaluation  of  SAFs  in  terms  of  overall 
mission  effectiveness  and  survivability  remains  in  the 
domain  of  Operational  Analysis,  evaluation  in  the 


above  described  context  aims  for  specific  questions 
such  as: 

•  What  is  the  operational  benefit  of  the  SAP 
component  currently  under  development  alone 
and/or  in  combination  with  other  SAFs  ? 

•  How  will  the  SAF  interact  with  other  avionic 
systems  in  an  aircraft,  in  particular  the  man 
machine  interface  ? 


Figure  5:  Airborne  Demonstrator 


Operational  performance  is  verified  and  evaluated 
mainly  in  the  Software  Technology  Environment  by 
simulation.  In  a  context  including 

•  different  threat  systems  with  various  deployments. 

•  3D  terrain  data, 

•  3D  flight  paths, 

•  terrain  masking  effects, 

•  aircraft  performance  characteristics, 

the  penetration  of  the  stealth  aircraft  is  simulated  and 
the  interaction  of  the  threats  with  the  aircraft  is  traced 
and  analysed  in  detail.  An  example  for  this  is  given  in 
chapter  6. 

To  demonstrate  the  interaction  of  the  SAF  with  the 
avionics  system  the  Avionics  Testbed  with  its 
functions  close  to  reality  is  used  together  with  the 
Software  Technology  Environment.  In  this  aircraft 
type  environment  the  correctness  of  data  exchange, 
the  timing  and  the  functionality  of  the  man  machine 
interface  are  evaluated.  The  results  of  different  flights 
are  recorded  and  can  be  rehearsed  afterward  with 
respect  to  operational  issues  in  the  scenario  simulation 
described  above. 

6  Example:  Fly  By  Signature 

To  demonstrate  the  above  discussed  development 
process  at  Dasa,  Fly  by  Signature  has  been  picked  as 
an  example  which  exhibits  a  number  of  the  elements 
involved  in  SAFs: 

•  mission  and  threat  representation. 

•  terrain. 

•  vehicle  manoeuvres. 

•  radar  cross  section  characteristics. 

•  on-board  sensors. 

•  route  optimisation  algorithms  accounting  for  threat 
avoidance,  terrain  masking,  RCS  relative  to  threat 
sensor  performance  and  system  lethality. 


14-5 


6.1  Principles  of  Flight  Path  Optimisation 

For  a  better  understanding  of  the  flight  path 
optimisation  approach  for  a  stealth  aircraft,  the  basic 
principles  are  outlined  for  a  less  challenging  example: 
planning  an  optimised  route  without  consideration  of 
RCS. 

A  scenario  is  set  up  by  placing  SAM  sites  in  a  terrain 
model  (see  figure  6,  with  threat  positions  marked  by 
letters  and  missile  ranges  shown  by  circles).  For  a 
specific  flight  level  the  areas  visible  to  the  different 
threats  are  calculated.  For  the  regions  not  masked  by 
terrain  “danger  arrays'*  are  attached  according  to  the 
threat  type.  Multiple  threats  are  cumulated.  (See  figure 
6  with  darker  grey  indicating  higher  threat  levels). 

For  given  start  and  end  points  the  optimised  route  is 
derived  by  minimising  the  integral  over  the  “danger 
areas**  with  constraints  imposed  by  the  flight  control 
system.  In  figure  6  the  optimised  route  is  shown  as  a 
dotted  curve. 


Figure  6:  Flight  path  optimisation  for  conventional 
aircraft 


6.2  Principle  of  Evaluation 

The  criterion  for  flight  path  evaluation  is  the 
susceptibility  of  an  aircraft  flying  through  such  a 
scenario  with  different  threats.  For  each  SAM  site  the 
track  possibility  will  be  calculated  and  the  time  an 
aircraft  is  exposed  to  it  gives  an  indication  of  the  risk. 

In  figures  7  and  8  this  track  capability  is  shown  for 
two  different  flight  paths  by  monitoring  the  lock-on 
intervals  (shown  by  dark  areas). 

6.3  Models 

Computationally,  the  above  example  is  based  on  a 
threat  radar  model  describing  the  radar  performance 


and  its  rules  for  moding  as  well  as  a  target  model 
describing  the  radar  cross  section  and  its  fluctuation. 


Figure  7:  Acquisition  (a)  and  track  (b)  probabi' 
lity  for  a  „Fly  by  Signature**  -  flight  path 


560.0  5B0..e  660.0  6?0.0  640.0  660.0  680.0  700.0  736.0  740,0  760.0  700 


Figure  8:  Acquisition  (a)  and  track  (b)  probabi 
lity  without  flight  path  optimisation 
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(b) 
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Target  Model 

Figure  9  shows  a  typical  radar  cross  section  (dB  scale, 
only  zero  elevation  shown)  for  a  stealth  aircraft.  For 
the  purpose  of  flight  path  optimisation  the  statistical 
fluctuations  of  the  aircraft  are  taken  into  account  by 
smoothing  the  RCS  (Fig.  10)  and  applying  Swerling  I 
statistics. 


Figure  9;  Calculated  RCS  of  a  stealth  aircraft 


Threat  Model 

We  assume  that  the  threat  systems  operate  both  with 
acquisition  and  track  radars. 
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The  acquisition  radar  scans  a  sector  and  its  main  beam 
will  (almost)  periodically  hit  the  target  when  it  is 
inside  the  sector. 

As  an  example,  figure  1 1  shows  the  performance  in 
terms  of  single  scan  detection  probabilities  of  the 
acquisition  radar  for  various  radar  cross  sections. 


Figure  10:  Smoothed  radar  cross  section 


Detection  is  modelled  via  cumulation  of  single  scan 
detection  probabilities  with  upper  and  lower 
thre.sholds.  The  detection  state  is  reported  for 
evaluation  on  the  one  hand  (see  figure  7,  8)  and 
triggers  the  employment  of  the  track  radar  on  the 
other  hand. 

Figure  12,  in  analogy  to  figure  11,  outlines  the 
performance  of  such  a  tracking  radar  in  terms  of 
single  look  detection  probability. 

Figure  11:  Single  scan  detection  probability  for  an 
acquisition  radar 
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Figure  12:  Single  scan  detection  probability  for  a 
track  radar 


Track  initiation  is  started  by  “handover**  from  the 
acquisition  radar.  Based  on  the  cumulated  detection 
probability  a  track  quality  parameter  is  recorded  and 
used  to  determine  the  threat  level  and  lock-on  state  via 


thresholds.  Lock-on  together  with  time  delays  means 
the  threat  is  ready  to  launch  a  missile. 

Therefore  the  reduced  duration  of  lock-on  states  is  the 
primary  pay-off  for  route  optimisation. 


6.4  Typical  result 

For  a  scenario  in  flat  terrain,  consisting  of  7  identical 
threats,  the  result  of  the  flight  path  optimisation  for  a 
trajectory  from  the  south-west  to  the  north-east,  is 
shown  in  figure  13.  Threat  sites  are  marked  by  letters, 
missile  ranges  by  circles,  the  resulting  flight  path  by  a 
dotted  line.  This  flight  path  takes  aircraft  performance 
and  flight-control  system  constraints  into  account. 
Speed  is  250  m  per  second,  and  compared  to  the 
shortest  route  the  flight  time  increases  from  800  to 
900  seconds. 


Figure  13:  Result  of  flight  path  optimisation 


The  flight  path  derived  from  flying  by  signature  shows 
-  on  the  first  glance  somewhat  unexpected  -  a  cycloid 
type  shape. 

When  comparing  a  straight  line  to  the  „Fly  by 
Signature**  flight  path  it  turns  out  that  without 
optimisation  each  of  the  seven  threats  builds  up  lock- 
on  intervals  exceeding  one  minute  (see  figure  8).  With 
optimisation 

•  3  of  the  7  threats  do  not  achieve  a  stable  track  and 
hence  would  not  be  able  to  launch  a  missile  against 
the  aircraft, 

•  For  3  of  the  remaining  threats  lock-on  time  is 
reduced  by  a  factor  2  or  more  (see  figure  7), 

•  For  one  threat  however,  no  significant 
improvement  arises. 

In  this  case  a  high  subclutter-visibility  was  assumed 
for  the  radar.  Lower  subclutter-visibility  would 
improve  the  result  as  long  low-radar  cross  sections  arc 
exposed. 


7  Conclusion 


Stealth  design  for  penetrating  aircraft  improves  their 
survivability.  However,  to  take  full  advantage  of  low 
signatures,  the  implementation  of  adapted  avionics  - 
signature  avionics  -  is  required. 

Due  to  the  manifold  interactions  of  stealth  design  with 
the  avionics  system  a  functional  breakdown  resulting 
in  signature  avionics  functions  has  turned  out  to  be 
necessary  to  identify  the  avionics  areas  affected. 

Due  to  new  requirements  emerging  from  the  stealth 
aircraft  characteristics,  careful  prototyping  of  these 
signature  avionics  functions  in  conjunction  with  a 
careful  and  accurate  evaluation  of  their  performance  is 
mandatory.  Suitable  prototyping  and  assessment 
environments  have  been  built  up  during  the  last  years 
at  Dasa-LM  and  have  proven  their  usefulness. 

In  our  view,  signature  avionics  is  an  essential  element 
of  future  combat  aircraft. 
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Abstract 

With  knowledge  of  persistent  data  communication  traffic 
patterns  offered  to  an  avionics  data  network,  modifications  to  the 
routing  through  the  network  can  be  made  to  improve  total 
throughput  and  bound  the  latency  of  packets.  The  Multiservice 
Switch  (MSS)  is  such  a  route-optimizing  switch  for  streaming 
sensor  data.  The  MSS  has  two  switching  fabrics:  packet 
switching  and  circuit  switching.  The  packet-switching  fabric 
routes  small  control  and  data  packets  between  switch  ports.  The 
circuit-switching  fabric  uses  a  crossbar  to  physically  connect 
ringlets,  which  reduces  the  workload  on  the  packet-switching 
fabric  for  long  data  streams  between  the  ports. 

An  implementation  of  the  MSS  is  described  which  uses 
commercial-offi-the-shelf  (COTS)  components.  A  simulation 
model  was  developed  to  show  the  benefits  of  the  MSS  under 
standard  avionics  workloads.  The  results  of  the  MSS  indicate 
distinct  advantages  in  terms  of  performance,  price,  and  power 
consumption  over  other  conventional  switch  and  network 
topology  designs. 

Introduction 

A  number  of  recent  studies  have  identified  a  requirement  for 
a  unified  avionics  data  netw'ork  that  is  capable  of  replacing  a 
variety  of  existing  interconnects  such  as  the  Parallel  Interface 
(PI)  Bus,  Data  Network/Data  Flow  Network  (DN/DFN),  High 
Speed  Data  Bus  (HSDB),  and  Sensor  Data  Distribution  Network 
(SDDN)  [UHLH92][SAE93].  For  example,  studies  performed 
under  the  Air  Force  PAVE  PACE  and  Very  High  Speed  Optical 
Networks  (VHSON)  programs  have  shown  that  by  integrating  the 
functionality  of  the  DN/DFN,  PI  Bus,  HSDB,  and  sensor/video 
network  into  a  single  network,  the  reliability’  of  the  interconnects 
could  increase  by  a  factor  of  13  while  reducing  cost  by  50%, 
weight  by  60%,  and  power  by  70%  [ULHL92].  As  a  result, 
system  designs  such  as  the  Joint  Strike  Fighter  (JSF)  preferred 
concept  feahue  a  unified  network  as  an  essential  component  of 
the  architecture  [JAST94]. 

One  of  the  difficulties  impeding  the  implementation  of  a 
unified  network  is  the  development  of  a  data  switch  capable  of 
supporting  the  conflicting  requirements  of  the  networks  being 
replaced.  For  example,  PI  Bus  traffic  is  characterized  by  short, 
low-latency  messages  which  would  best  be  handled  by  a 
connectionless,  packet-switched  transfer  whereas  DN/DFN  traffic 
is  characterized  by  stream  data  best  handled  by  a  connection- 
oriented,  circuit-switched  network.  Sensor  data  is  a  mix  of  the 
two  in  that  it  is  mostly  stream  data  interrupted  occasionally  by 
very-low-latency,  high-integrity  control  and  status  information. 
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In  this  paper  we  describe  the  development  of  a  compact,  low- 
power  multiservice  switch  capable  of  supporting  both 
connectionless  and  connection-oriented  transfers.  The  switch 
operates  at  a  1-Gbps  serial  data  rate  and  the  inputs  and  outputs 
are  optical.  The  switch  is  based  on  the  IEEE  1596-1992  Scalable 
Coherent  Interface  (SCI)  standard  [SCI93].  This  standard 
supports  a  number  of  interconnect  topologies  including  ringlets, 
switched  networks,  and  ringlets  interconnected  by  switches 
which  make  it  suitable  for  multiservice  transfers.  The  MSS 
provides  multiservice  support  by  incorporating  a  crossbar  switch 
which  reconfigurably  interconnects  ringlets  to  form  larger 
ringlets.  In  addition,  each  input  port  is  connected  by  a  back-end 
bus  which  reroutes  messages  addressed  to  nodes  on  other 
ringlets.  Stream  data  transfers  are  supported  by  connecting  the 
source  and  target  nodes  on  a  common  ringlet  via  the  crossbar 
switch,  while  small,  bursty'  transfers  are  supported  via  the  back¬ 
end  bus. 

The  advantage  of  this  topology  is  that  the  back-end  bus  is 
only  used  to  transfer  relatively  short  control  and  status  messages, 
so  that  very-low  latency  can  be  achieved  for  these  messages.  An 
added  advantage  is  that  the  power,  size,  and  cost  of  the  switch 
are  much  lower  than  in  a  switch  that  must  provide  high-spieed, 
exclusively-coimectionless  transfers.  In  the  next  sections  we 
describe  the  functional  design  of  the  switch  and  predicted 
porformance  and  power  dissipation  for  a  5-port  (4  SCI  ports,  1 
control  port)  prototype  currently  undergoing  test  and  evaluation. 
This  switch  is  based  on  the  Dolphin  LC-1  link  controller  chip 
which  uses  interval  routing.  We  also  describe  the  results  of 
simulations  that  predict  the  porformance  of  a  switch  based  on 
look-up  table  routing  which  would  provide  greater  system 
flexibility'.  Finally,  brief  conclusions  are  draw'n  about  the 
porformance  and  utility  of  the  multiservice  switch. 

SCI  Overview 

SCI  is  a  unidirectional,  point-to-point,  high-porformance 
network  protocol  ■with  a  standard  bandwidth  of  1-GBps  and  a 
media  access  control  using  register  insertion  ring  for  low-latency 
concurrent  transfers.  SCI  is  a  synchronous  protocol  and  emits  a 
single  1 8-bit  symbol  at  each  clock  cycle.  SCI  packets  are  made 
up  of  a  series  of  delimited  symbols.  The  internal  structure  of  an 
SCI  node  is  shown  in  Figure  1 . 

Incoming  SCI  packets  arrive  and  are  routed  either  to  the  input 
queue  or  to  the  bypass  FIFO  by  the  strip)p)er  based  on  the 
destination  address  of  the  packet.  The  host  interface  services  the 
input  queue  and  offers  new'  packets  into  the  output  queue.  A 
multiplexer  arbitrates  between  the  bypass  FIFO  and  output  queue 
for  transmission  onto  the  SCI  ring. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems’’,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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Packets  Packets 

_ Figure  1:  SCI  Node _ 

Common  SCI  topologies  are  ring-based  so  that  packets  are 
passed  through  the  bypass  FIFOs  of  intermediate  nodes  on  their 
way  to  the  destination  node.  Although  rings  are  the  easiest 
topolog)’  to  create  using  SCI  nodes,  they  suffer  from  a  lack  of 
fault  tolerance  and  a  minimum  latency  proportional  to  the  number 
of  intermediate  nodes.  SCI  switches  are  used  to  connect  separate 
SCI  rings  in  an  attempt  to  increase  both  fault  tolerance  as  well  as 
improve  performance  by  routing  packets  out  of  rings  to  save 
bandwidth.  Switches  have  a  penalty  of  routing  delay,  which  is 
necessary  for  all  packets  that  are  routed  by  the  switch.  Certainly 
a  trade-off  between  the  performance  improvements  of  a  switch 
and  the  streaming  performance  of  the  ring  can  be  made. 


Switch  Design 

Figure  2  shows  a  functional  block  diagram  of  the  multiservice 
switch  The  default  configuration  has  the  crossbar  simply 
passing  packets  from  the  same  numbered  input  port  to  output 
port.  Figure  3  shows  a  schematic  of  an  individual  port  inside  the 
switch.  Each  port  on  the  MSS  is  connected  to  an  SCI  ringlet 
consisting  of  several  nodes.  The  serial  optical  input  signal  at  each 
port  is  converted  to  an  electrical  signal  and  inputted  to  an 
Hewlett  Packard  G-Link  chip  for  deserializing  and  decoding. 


The  parallel  format  is  required  for  SCI  node  interface  (i.e.  the 
Dolphin  LC-1)  that  receives  it  next.  The  output  of  the  LC-1  is 
encoded,  converted  back  to  serial,  and  sent  to  one  of  the  inputs  of 
a  serial,  electronic-crossbar  switch.  The  corresponding  output  of 
the  crossbar  is  converted  to  an  optical  signal  and  routed  to  the 
output  of  the  port,  where  it  completes  the  ringlet.  The  crossbar 
switch  is  controlled  via  a  parallel  port  which  may  be  attached  to  a 
host  processor  connected  to  any  node  on  the  network.  The  same 
host  controls  the  initialization  and  status  of  the  LC-1  chip  at  each 
port  via  separate  control  logic.  The  node  interfaces  at  each  port 
are  connected  together  via  a  back-end  bus  (i.e.  the  B-bus  in 
Figure  2).  Packets  addressed  to  a  ringlet  other  than  the  one  to 
which  the  port  is  connected  are  stripped  from  the  ringlet  by  the 
interface  circuit  and  routed  to  the  appropriate  ringlet  via  the 
back-end  bus. 


Individual  ringlets  may  be  connected  together  through  the 
crossbar  switch  to  form  a  single  ringlet.  For  example,  if  the 
crossbar  switch  is  configured  so  that  input  1  is  coimected  to 
output  4  and  input  4  is  connected  to  output  1 ,  all  of  the  nodes  in 
ringlets  i  and  4  actually  reside  on  a  common  ringlet.  A  typical 
configuration  might  consist  of  a  sensor  on  one  ringlet  connected 
to  a  second  ringlet  comprised  of  a  suite  of  processing  and 
memory'  modules.  Stream  data  from  the  sensor  is  transferred  to 
the  processing  suite  through  the  crossbar  switch.  Short  control 
and  status  messages  from  or  to  nodes  residing  on  different 
ringlets  are  transferred  over  the  back-end  bus.  Since  only  the 
low-data-rate  control  and  status  messages  are  transferred  over  the 
back-end  bus,  very-low  latency  for  these  messages  can  be 
achieved. 

In  normal  operation  reconfiguration  would  occur  only  in  the 
case  of  component  failure,  battle  damage,  or  change  of  mission. 
A  reconfiguration  may  be  initiated  by  any  node  by  sending  a 
request  to  the  node  controlling  the  crossbar  switch.  If  the  request 
is  valid,  this  node  instructs  the  interface  circuits  at  the  switch 
ports  to  begin  issuing  reset  commands  around  the  affected 
ringlets.  The  crossbar  switch  is  then  set  and  the  affected  ringlets 
are  allow'ed  to  reinitialize  in  the  standard  way.  During 
initialization  new  node  IDs  are  assigned  to  each  node  if 
necessary.  The  entire  process  is  estimated  to  take  less  than  1  ms. 
In  comparison,  the  SAE  requirement  for  reconfiguration  of  an 
SDDN  is  50  ms  [SAE93]. 

The  current  prototype  operates  at  a  serial  data  rate  of  1-Gbps. 
This  rate  is  limited  by  the  speed  of  the  crossbar  switch.  If  a 
faster  electrical  or  optical  switch  were  available  the  ultimate 
speed  of  the  switch  would  be  1 .6-Gbps,  limited  by  the  speed  of 
the  interface  circuitry.  The  back-end  bus  operates  at  an  aggregate 
data  rate  of  3.2-Gbps. 

The  pow'er  dissipation  of  the  switch  may  be  estimated  from 
the  individual  components.  Each  port  consists  of  an  optical 
transceiver,  a  serializer/deserializer,  interface  circuit,  and 
assorted  line  drivers.  Total  power  dissipation  for  these 
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components  is  11.15  W,  In  addition,  the  crossbar  switch  and 
control  logic  dissipate  5.4  W.  Total  power  dissipation  for  the  5- 
port  prototype  is  estimated  to  be  61.15  W.  A  16-port  version 
would  dissipate  1 83.8  W. 

Simulation  Descriptions 

The  following  sections  provide  descriptions  of  the  models 
that  were  created  to  simulate  the  SCI  protocol  and  different  SCI 
switches  to  measure  the  jjerfonnance  of  complete  systems.  The 
SCI  emulation  model  provides  the  basic  SCI  transport  operations 
in  a  fine-grain  maimer.  The  switch  models  extend  the  emulation 
model  to  simulate  a  packet-level  switch  as  well  as  the  MSS. 
Three  example  systems  are  presented  and  network  loading 
scenarios  are  described  to  show  the  relative  benefits  of  each  of 
the  topologies.  Finally,  results  of  the  simulations  are  jjresented 
and  analyzed. 

SCI  Emulation  Model 

The  SCI  emulation  model  was  designed  and  implemented 
using  the  Block-Oriented  Network  Simulator  (BONeS)  from  the 
Alta  Group  of  Cadence  Systems,  Inc,  BONeS  is  a  discrete-event 
simulator  with  many  built-in  modeling  blocks  for  fine-grain 
network  simulation.  The  SCI  emulation  model  was  designed  to 
follow  the  SCI  standard  as  closely  as  possible,  sacrificing 
minimal  fidelity  to  improve  simulation  speed.  The  model  has 
many  parameters  that  can  be  set  to  match  experimental 
measurements  of  existing  SCI  hardw'are.  In  this  way,  specific 
hardware  implementations  can  be  simulated  by  calibrating  the 
model  using  these  parameters. 

The  model  was  built  to  be  generic  and  reusable  although 
some  design  parameters  were  assumed.  First,  packet  routing  is  of 
prime  importance  when  modeling  any  switches.  The  SCI  node 
routing  decisions  are  made  by  table  lookups  of  routing  tables 
w'hich  are  dynamic  and  c£m  be  rewritten  during  simulation  if 
reconfiguration  occurs.  Generic  routing  tables  can  also  simulate 
static-routing  schemes  such  as  interval  routing.  A  SNTnbol-level 
simulation  is  most  desirable  for  fidelity  purposes  but  can  lead  to 
extremely  long  simulation  times.  Instead,  two  modeling 
techniques  were  used  to  improve  simulation  time.  First,  any 
output  symbols  of  a  contiguous  SCI  packet  are  clumpied  together. 
In  this  way,  only  one  event  is  triggered  once  a  packet  is  received 
instead  of  the  40  events  for  a  40-  symbol  send  packet.  Second, 
the  packet  undergoes  a  ‘"pipelined”  delay  during  reception.  This 
technique  forces  the  receiving  node  to  delay  until  the  needed 
symbol  of  the  packet  arrives  before  it  is  allowed  to  use  the 
information.  In  this  way,  exact  bypass  and  routing  delays  can  be 
simulated  with  great  accuracy. 

Each  node  has  an  adjustable  clock  frequency  and  is  assumed 
to  output  a  single  18-bit  symbol  during  each  clock  period.  Hence, 
serial  SCI  nodes  can  be  simulated  by  appropriate  clock  frequency 
selections.  The  node’s  host  interface  is  separately  clocked  to 
simulate  a  different  speed  host.  The  host  interface  was  designed 
to  support  either  an  asynchronous  or  synchronous  host.  An 
asynchronous  host  offers  traffic  at  an  arbitrary  rate  and  will 
process  rejected  packets  if  the  output  queue  is  full.  An 
asynchronous  host  will  attempt  to  service  the  input  queue  as 
quickly  as  possible.  If  the  host  is  not  available,  the  host  rejects 
the  incoming  packet  which  is  pushed  back  into  the  input  queue. 
If  the  host  cannot  service  incoming  packets  at  a  sufficient  rate, 
the  input  queue  will  fill  which  forces  new  packets  to  be  retried 
using  SCTs  queue  reservation  protocols  for  retried  packets. 


Synchronous  hosts  offer  packets  at  a  constant  rate  to  the 
output  queue  and  service  packets  at  a  constant  rate  from  the  input 
queue.  This  mode  of  packet  handling  simulates  constant  rate 
sources  such  as  sampling  sensors  and  constantly-polled  input 
sinks.  The  modeled  interface  was  designed  in  such  a  way  to 
support  both  timing  methods  simultaneously. 

SCI  Switch  Models 

A  packet  switch  is  shown  in  Figure  4  and  is  built  of  multiple 
SCI  nodes.  The  host  interfaces  of  the  nodes  in  the  switch  are 
connected  to  a  common  fabric  such  as  a  shared  bus. 


The  MSS  is  built  by  combining  a  packet  switch  with  a 
crossbar  to  allow'  switching  of  physical  circuits.  This  design  is 
shown  in  Figure  5.  Notice  that  once  rings  are  combined  using  the 
crossbar,  the  SCI  nodes  inside  the  switch  simply  pass  packets 
destined  for  a  node  on  the  new'  ring  through  their  bypass  FIFOs 
instead  of  stripping  them  off  and  passing  them  over  the  packet 
switching  fabric. 


Simulated  Systems 

A  simple  SCI  ringlet  system,  shown  in  Figure  6,  was  used  as 
a  baseline  for  comparisons  of  latency,  throughput,  and  response 
time  variance.  The  ringlet  is  formed  by  connecting  the  output 
link  of  one  node  to  the  input  link  of  the  following  node  and 
requires  no  additional  hardware.  A  system  of  4  nodes  connected 
with  a  packet  switch  was  used  to  verify  the  routing  performance 
of  the  switch.  The  packet  switch  system  is  shown  in  Figure  7. 
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This  configuration  offers  a  separate  ringlet  per  node  and  requires 
a  high-performance,  packet-switching  fabric  to  maintain  high 
throughput.  Finally,  a  system  built  with  an  MSS  is  shown  in 
Figure  8,  The  configuration  is  isomorphous  to  Figure  7,  as  the 
MSS  is  topologically  identical  to  a  packet  switch. 


Simulation  Scenarios 

In  order  to  gauge  the  effectiveness  of  the  multiservice  switch, 
the  three  systems  described  above  were  implemented  in  the 
simulation  environment.  Each  node  of  the  system  was  configured 
with  a  statistical  requester  and  an  active  responder.  The 
requester  has  four  types  of  parameters  that  can  be  varied  to 
simulate  certain  classes  of  data  sources:  request  type,  interarrival 
type,  burst  type,  and  destination  type. 

•  The  request  type  specifies  which  commands  this  requester 
will  generate  and  at  what  size.  Common  commands  are 
read,  write,  and  move  with  standard  payload  sizes  of  64  or 
256  bytes  per  request.  A  read  command  requests  a  certain 
block  of  memory  from  the  responder,  which  generates  a 
response  packet  with  the  data.  A  write  command  passes  a 
block  of  data  to  the  responder  to  write  into  memory  .  The 
responder  replies  with  a  response  packet  once  the  data  has 
been  committed  into  memory.  A  move  command  writes  data 
from  the  requester  to  the  responder  but  eliminates  the 
resjxinse  subaction. 

•  The  interarrival  type  specifies  the  time  between  subsequent 
requests.  Available  interarrival  rates  are  fixed  or  random 


with  uniform,  exponential,  or  normal  distributions.  The 
mean  and  variance  can  be  specified. 

•  The  burst  type  specifies  how  many  requests  are  generated  in 
a  stream  from  tliis  requester.  The  number  of  requests  can  be 
fixed  or  random  with  uniform,  exponential,  or  normal 
distribution,  again  with  mean  and  variance  as  parameters. 

•  The  destination  type  specifies  where  requests  from  this  node 
will  be  sent.  The  available  destinations  are  fixed,  random 
with  uniform  distribution,  downstream  (next  node  on  ring), 
upstream  (previous  node  on  ring),  and  self 

By  selecting  the  appropriate  parameters  of  the  source, 
different  loading  conditions  on  the  netw'ork  can  be  investigating 
in  hopes  to  predict  actual  performance.  Parameters  that  specify 
SCI  node  performance  can  also  be  varied  and  reasonable  choices 
were  chosen.  Table  1  lists  the  extemally-variable  node 
parameters  and  the  values  chosen  throughout  all  simulations. 


Table  1:  SCI  Simulation  Parameters 


Parameter 

Value 

Input  Queue  Size 

3 

Output  Queue  Size 

Number  of 
outstanding 
transactions 

3 

Link  Data  Rate 

Speed  that  raw 
data  is  passed  over 
SCI 

1.6  Gbps 
(i.e.  200  MBps) 

Host  Data  Rate 

Speed  that  raw- 
data  is  passed  from 
tlie  SCI  node  to  the 
host 

1 .6  Gbps 
(i.e.  200  MBps) 

Switch  Data  Rate 

Speed  that  raw 
data  is  passed 
through  the  packet 
s-witching  fabric 

3.2  Gbps 
(i.e.  400  MBps) 

Stripping  Delay 

Symbols  necessary 
to  determine 
packet  destination, 
w/  no  routing  table 
check 

2  symbols 

Routing  Table 

Delay 

Symbols  necessary 
to  delay  while 
checking  the 
routing  table 

40  symbols  (store 
and  forw  ard 
s-witches) 

Link  Length 

Length  of 
electrical  -wiring 
runs  between 
nodes 

3  meters 

Each  of  the  three  network  configurations  was  offered  the 
three  following  loading  conditions  to  allow  a  fair  comparison 
between  the  topologies.  Table  2  summarizes  in  qualitative  terms 
the  expiected  results  of  the  simulation. 

1 .  The  first  loading  condition  is  a  streaming  test  This  involves 
two  nodes  (the  first  and  the  fourth)  in  which  node  1  sends 
64-by'te  move  packets  to  node  4  at  a  fixed  rate.  The 
throughput  and  latency  is  calculated  at  the  responder  node. 
This  test  forms  the  upper  bound  in  throughput  for  the 
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specific  topolog>'.  The  switched  MSS  system  performance  is 
expected  to  match  the  ringlet  system  while  the  packet 
switched  system  will  have  a  slight  decrease  in  throughput 
due  to  routing  delays. 

2.  The  second  loading  condition  offers  a  varying  total  offered 
load  to  each  system  where  each  node  sends  a  fixed  burst 
length  of  read  and  write  requests  to  a  random  responder  with 
a  Poisson  distributed  interarrival  rate.  The  latency  and 
throughput  is  measured  at  the  requester  since  reads  and 
writes  are  response-expected  transactions.  The  ring 
performance  is  expected  to  be  poor  since  the  ring  bandwidth 
is  fairly  shared  among  all  4  nodes.  The  two  switches  are 
exp)ected  to  perform  identically  since  the  MSS  gains  no 
advantage  of  circuit  switching  tmder  random  traffic.  The 
switched  systems  will  enjoy  a  much  higher  aggregate 
throughput  than  the  ring  system  due  to  the  separated 
ringlets. 

3.  The  final  loading  condition  combines  the  first  two  to  mimic 
a  typical  avionics  sensor-processing  workload.  Node  1  is 
specified  as  a  source  node  and  streams  data  to  node  4. 
Simultaneously,  all  nodes  except  node  1  send  out  fixed  burst 
messages  to  random  destinations.  The  streaming  load  is 
made  up  of  64-byte  move  transactions  and  is  representative 
of  sampled  data  fi'om  a  sensor.  The  random  load  is  typical 
of  control  messages  and  uses  an  exponential  interarrival  rate 
to  simulate  computer-generated  traffic.  The  streaming  data 
is  designed  to  utilize  10  times  the  bandwidth  of  the 
combined  random  load.  Actual  SAE  specifications  cite 
streaming  loads  up  to  2-Gbps  and  control  loads  up  to  1- 
MBps,  a  200:1  ratio  [SAE93].  In  this  final  case,  the  MSS 
should  show  the  streaming  performance  of  the  ring  and  the 
burst)'  performance  of  a  switch  while  the  packet  switched 
system  and  the  ring  system  will  perfonn  worse  due  to 
topological  constraints. 


Table  2:  Qualitative  Expected  Results 


Streaming 

Random 

Mixed 

Ring 

Good 

Poor 

Poor 

Packet  Switch 

Poor 

Good 

Poor 

MSS 

Good 

Good 

Good 

Offered  Load  (MBdsI 


Figure  9:  Streaming  Scenario  Throughput  Results 


Figure  9  shows  that  all  three  topologies  can  handle  a  single 
source  saturating  the  network  and  all  three  saturate  at  the  same 
rate  (i.e.  160  MBps,  ■which  is  40  MBps  less  than  the  link  data 
rate  due  to  packet  overhead).  This  chart  does  not  show  how 
nmch  bandwidth  is  available  after  the  network  saturates.  Since 
the  ring  topology  shares  bandwidth,  very  little  bandwidth  is 
available  with  a  single  high-load  source.  Both  of  the  switch 
systems  still  have  full  bandwidth  available  on  ringlets  2  and  3. 
The  packet  switch  system  has  half  of  the  internal  fabric 
bandwidth  remaining  while  the  MSS  has  the  full  internal  fabric 
bandwidth  remaining. 


Offered  Load  (MBps) 


Figure  10:  Streaming  Scenario  Latency  Results 


Simulation  Results 

The  simulation  results  are  grouped  into  sections  based  on  the 
three  loading  conditions.  The  first  set  of  graphs  shows  the 
throughput  and  latency  for  the  streaming-load  scenario. 


Figure  10  shows  the  latency  for  the  streaming-load  scenario. 
The  packet  s'witch  system  has  a  fundamentally  higher  latenc)' 
than  both  the  ring  and  MSS  systems.  This  is  the  routing  delay. 
Both  the  MSS  and  ring  avoid  any  packet  switching  and  therefore 
enjoy  a  lower  minimum  latency  by  approximately  0.4  ps.  The 
MSS  has  a  slightly  lower  latency  than  the  ring  due  to  the 
configuration.  The  number  shown  is  the  two-way  latenc)  of 
packets  that  were  actually  received.  In  the  overloading  case, 
latency  is  irrfinite  since  some  packets  will  never  reach  their 
destinations  so  an  appropriate  number  W'as  chosen  for  displa)' 
purposes. 
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Figure  1 1  shows  the  throughput  of  the  random  load  scenario. 
This  scenario  shows  the  benefit  of  using  a  switched  topwlogy. 
Notice  how  the  saturation  bandwidth  of  both  switched  systems  is 
higher  than  the  ring  which  saturates  at  166  MBps  The  MSS, 
which  has  nodes  1  and  4  circuit  switched  onto  the  same  ringlet, 
has  a  higher  bandwidth  than  the  ring  due  to  its  packet  switch 
fabric  but  has  a  smaller  throughput  than  the  switched  system  due 
to  the  circuit-switched  ringlet.  Here,  approximately  half  of  the 
load  uses  the  ring  while  half  uses  the  packet  switching  (due  to 
uniform  distribution  of  destinations).  Hence  the  performance  of 
the  MSS  system  is  about  halfway  between  the  packet  switched 
system  and  the  ring  system. 

Figure  12  shows  the  latency  for  the  random  destination 
loading  scenario.  A  distinction  between  the  three  systems  can  be 
seen  here.  Again,  the  performance  of  the  MSS  system  is 
approximately  halfway  between  the  ring  system  and  the  packet- 
switched  system.  The  packet-switched  network  has  the  lowest 
average  latency  for  the  random  destination  case.  This  occurs  due 
to  the  sharing  of  bandwidth  on  the  ring  system  as  well  as  the 
ringlet  in  the  MSS  system. 


Figure  13  shows  the  mixed  load  throughput  results.  Again, 
all  three  systems  are  able  to  saturate  the  network  at  the  streaming 
load  limit  of  150  MBps.  Recall  that  the  mixed  load  is  composed 
of  the  streaming  load  from  node  1  and  the  random  destination 
load  that  is  1/10*  the  streaming  load  (i.e.  nodes  2,3,  and  4 
transmit  at  1/30*  the  rate  as  node  1 ). 


Figure  14  shows  the  latency  of  the  mixed  load  scenario. 
Here,  only  two-way  latency  of  the  random  destination  packets  for 
comparison  with  the  random  destination  test.  Under  the  mixed 
load  scenario,  the  MSS  system  maintains  the  lowest  average 
latency  for  the  random  destination  packets  while  also  having 
throughput  that  is  as  equally  high  as  the  other  topologies. 

Conclusions 

This  paper  presented  the  design,  modeling,  and  simulation  of 
a  novel  switching  technique  for  next  generation  avionics  data 
networks.  The  multiservice  switch  offers  two  switching 
mechanisms  to  gain  the  performance  and  fault-tolerance  benefits 
of  a  packet  switch  while  simultaneously  offering  the  low  latency 
of  a  ring-based  topology. 

The  performance  improvements  of  the  multiservice  switch 
will  allow  system  designers  to  reduce  the  packet  switch  speed 
requirements  to  attain  the  same  level  of  performance  for 
streaming  loads.  By  reducing  the  speed  of  the  packet  switch, 
power  and  cost  are  reduced.  The  multiservice  switch  also  show  s 
equal  if  not  better  performance  than  conventional  switches  and 
topologies  for  mixed  offered  loads,  which  can  be  expected  in  an 
avionics  data  network. 


Future  Research 

Future  work  on  the  multiservice  switch  will  complete  the 
prototype  switch  in  both  hardware  and  software.  The  prototype 
switch  still  requires  control  software  to  be  written  and  some 


hardware  debugging.  The  simulator  will  be  expanded  to  handle 
actual,  rather  than  statistical,  offered  loads  and  to  include  more 
efficient  switching  mechanisms.  The  simulator  will  also  be 
expanded  to  simulate  the  actions  necessarx’  for  a  run-time 
crossbar  reconfiguration. 
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1  ABSTRACT 

This  paper  describes  the  research  and  experiments  carried  out 
by  the  National  Aerospace  Laboratory  (NLR)  in  the  field  of 
high-speed  interconnection  systems  for  modular  avionics.  The 
research  has  been  carried  out  in  the  EUCL1D/RTP4. 1  - 
framework. 

The  avionics  network  that  was  modelled  and  simulated  was  an 
optical  switch  matrix  under  control  of  a  cell  switched  network. 
The  optical  switch  matrix  offers  the  avionics  system  circuit- 
switched,  uni-directional,  point-to-point  connections.  A  ' 
bandwidth  of  2  Gbps  is  projected.  The  main  purpose  of  the 
matrix  is  to  connect  sensors  producing  high  data  rates,  such  as 
an  attack  radar  in  fighter  aircraft,  with  the  core  avionics 
processing  cluster. 

The  cell  switched  network  -  in  this  case  Asynchronous 
Transfer  Mode  (ATM)  -  controls  the  optical  switch  matrix  and 
provides  data  transfer  at  lower  data  rates,  file  transfer,  and 
status  messages.  The  simulation  model  operated  ATM  at  149 
and  622  Mbps. 

The  primary  objective  of  our  research  was  to  assess  ATM  as  a 
data  link  layer  for  a  control  and  message  network  in  an 
avionics  data  network.  The  computer-based  tool  to  model  the 
network  was  SES/Workbench. 

2  ABBREVIATIONS 


AAL 

ATM  Adaptation  Layer 

ABR 

Available  Bit  Rate 

ATM 

Asynchronous  Transfer  Mode 

B 

Byte 

B-ISDN 

Broadband  ISDN 

CBR 

Constant  Bit  Rate 

CCITT 

Consultative  Committee  for  International 
Telegraphy  and  Telephony 

CMN 

Control  and  Message  Network 

DMA 

Direct  Memory  Access/ Addressing 

EO 

Electro-Optical 

EUCLID 

European  Co-operation  for  Long  term  In 
Defence 

Gbps 

Giga  bits  per  second 

Hz 

Hertz 

ISDN 

Integrated  Services  Digital  Network 

ITU-T 

International  Telecommunications  Union, 
Telecom  Standards  Sector 

kB 

kilo  Byte 

LAN 

Local  Area  Network 

LCE 

Link  Control  Element 

Mbps 

Mega  bits  per  second 

NLR 

National  Aerospace  Laboratory 

OSM 

Optical  Switch  Matrix 

PVC 

Permanent  Virtual  Circuit 

QoS 

Quality  of  Service 

RE 

Radio  Frequency 

RISC 

Reduced  Instruction  Set  Chip 

RTP 

Research  and  Technology  Programme 

SCI 

Scaleable  Coherent  Interface 

SDH 

Synchronous  Digital  Hierarchy 

SES 

Scientific  &  Engineering  Software  Inc, 

STM 

Synchronous  Transfer  Module 

VBR 

Variable  Bit  Rate 

VC 

Virtual  Circuit 

WAN 

Wide-Area  Network 

WEAG 

Western  European  Armament  Group 

3  INTRODUCTION 

This  paper  describes  the  experiments  and  the  results  of 
research  in  the  field  of  high-speed  interconnection  systems  foi 
modular  avionics.  This  research  has  been  carried  out  in  the 
framework  of  EUCLID  RTF  4.1. 

3.1  Project  background 

The  European  Co-operation  for  Long  term  In  Defence 
(EUCLID)  Research  and  Technology  Programme  4.1 
“Modular  Avionics  Harmonisation  Study”  identified  and 
researched  the  technologies  available  in  Europe  for  the 
development  of  future  avionics  systems  architectures.  The 
programme  was  a  joint  effort  of  27  companies  in  6  European 
nations:  France,  Germany,  United  Kingdom,  Spain,  Italy,  and 
the  Netherlands,  The  consortium  consisted  of  most  European 
airframe  manufacturers  and  equipment  suppliers.  EUCLID  is  a 
programme  of  the  Western  European  Armament  Group 
(WEAG). 

The  in-service  time  frame  of  the  envisioned  avionics  systems 
was  2005-2010.  The  target  programme  can  either  be  a  retrofit 
of  an  existing  aircraft  or  the  development  of  a  new  aircraft. 

The  types  of  activities  in  the  programme  involved  definitions, 
specifications,  surveys,  simulations,  and  laboratory 
demonstrations. 

The  areas  in  which  the  National  Aerospace  Laboratory  (NLR) 
was  involved  covered  the  following  topics: 

•  high-speed  interconnection  systems; 

•  digital  signal  processing; 

•  fault-tolerance; 

•  component  and  rack  cooling; 

•  system  development  tools. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems",  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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This  paper  focuses  on  our  activities  in  the  field  of  high-speed 
interconnection  systems,  the  modelling  and  simulation  thereof 
in  particular. 

3.2  Modular  avionics  architecture 

The  avionics  architecture  defined  in  the  programme  formed 
the  basis  for  the  simulation  model.  The  core  avionics 
architecture  consists  of  ten  functional  areas  and  a  unified  data 
network  interconnecting  the  functional  areas.  The  ten 
functional  areas  are  vehicle  control,  crew  interface  control, 
mission  control,  systems  control,  data  base  control,  RF,  EO, 
image  analysis,  image  generator,  and  acoustics.  Each 
functional  area  hosts  a  group  of  related  functions  to  optimise 
the  traffic  across  the  network.  Reference  1  describes  in  detail 
the  rationale  for  the  division  of  the  core  avionics  into 
functional  areas. 

The  following  modules  are  the  building  blocks  for  the 
functional  areas:  data  processing,  signal  processing,  image 
processing,  graphics  processing,  and  memory  modules,  With 
the  continuous  increase  in  performance  of  processing  devices, 
it  is  likely  that  eventually  all  processing  takes  place  on  generic 
processing  modules. 

Table  1  on  page  16-8  shows  the  expected  data  traffic 
categories  and  their  characteristics  (Ref  2),  These  categories 
and  characteristics  formed  the  basis  for  the  workload  for  the 
simulations. 

Analysis  of  the  data  traffic  shows  that  the  avionics  network 
shall  support  three  basic  types  of  transmissions: 

1 .  sustained,  large  amounts  of  data; 

2.  bursty,  medium  sized  amounts; 

3.  short,  but  time  critical  messages. 

To  be  able  to  service  this  variety  of  transmission  types,  a  dual 
network  approach  was  chosen.  The  dual  network  is  called  the 
‘Matrix  Switched  Network’  (MSN).  The  MSN  provides: 

•  a  connection-oriented  data  transfer  network  for  sustained, 
large  amounts  of  data,  typically  originating  from  sensors; 

•  a  control  and  message  network  to  control  access  to  the 
data  transfer  network  and  to  facilitate  transmission  of 
bursty,  medium  sized  amounts  of  data. 

For  the  control  and  message  network,  the  following  protocols 
have  been  evaluated:  1553,  FDDI,  ATM,  and  SCI.  ATM  came 
out  as  most  promising  candidate,  closely  followed  by  SCI. 

Because  of  the  limited  amount  of  resources  we  were  able  to 
model  one  type  of  protocol.  For  several  reasons  we  decided  to 
go  for  ATM: 

•  ATM  came  out  of  the  evaluation  as  most  suitable; 

•  ATM-technology  is  available  on  the  market; 

•  there  are  several  commercial  as  well  as  academic  models 
available. 

3.3  Objectives  of  the  modelling  and  simulation 

Our  research  involved  the  modelling  and  simulation  of  a 
typical  functional  area  with  the  following  three  objectives: 


1 .  Development  of  a  model  of  the  core  avionics  architecture 
defined  in  the  programme. 

2.  Performance  modelling  of  the  avionics  architecture  model. 

3.  Assessment  of  ATM  as  data  link  layer  for  a  control  and 
message  network  for  an  avionics  data  network. 

4  DESCRIPTION  OF  THE  NETWORK  MODEL 

Before  explaining  how  an  ATM  network  can  be  used  as  a  data 
link  layer  for  a  control  and  message  network,  an  introduction 
to  ATM  networks  will  be  given  in  section  4.1.  Section  4.2 
explains  how  an  ATM  network  can  be  used  as  a  basis  for  the 
control  and  message  network.  Section  4.3  describes  the 
limitations  of  the  model.  Section  4.4  describes  the  simulation 
tool  SES/Workbench  briefly. 

4.1  Introduction  to  ATM 
In  the  mid-1980s  when  the  ISDN  standard  was  being 
developed,  the  CCITT  began  working  on  the  successor  of 
ISDN;  it  was  acknowledged  that  ISDN  would  not  offer 
enough  bandwidth  in  the  future.  This  successor  is  known  as 
Broadband  ISDN  (B-ISDN).  One  key  objective  was  to 
develop  a  technology  that  would  allow  for  efficient  transport 
of  all  kinds  of  traffic  (bursty  and  isochronous).  Further,  the 
new  technology  should  support  future  speeds  of  several 
Gigabits  per  second  (Gbps).  In  1988  the  CCITT  decided  to 
base  the  development  of  B-ISDN  on  ATM  which  was 
formalised  in  the  late  1980s.  B-ISDN  became  one  of  the 
services  that  can  use  ATM  technology, 

ATM  is  a  relatively  new  method  to  transport  information. 

Two  classical  ways  of  transporting  information  are: 

•  Circuit  switching:  requires  a  circuit  to  be  established  prior 
to  transport  of  data.  Resources  in  the  network  stay 
reserved  until  the  connection  is  tom  down.  Circuit  swit¬ 
ching  is  well  suited  for  isochronous  traffic.  ISDN  and  the 
classical  telephone  network  are  examples  of  the  use  of 
circuit  switching. 

•  Packet  switching:  suitable  for  bursty  data  transmission  and 
unsuitable  for  isochronous  applications.  It  is  more 
efficient  than  circuit  switching,  because  network  resources 
are  only  used  when  traffic  is  present.  Packet  switching  is 
used  in  LAN  environments, 

ATM  is  a  cell  switching  technique.  Cells  are  small,  fixed- 
length  packets  of  53  Bytes  that  are  switched  to  their 
destination  by  the  hardware  in  network  nodes  (ATM 
switches).  Cells  can  carry  data  from  arbitrary  applications 
(isochronous  as  well  as  bursty).  ATM  systems  are  connected 
to  ATM  switches  by  a  dedicated  link;  there  is  no  shared 
medium  like  in  LANs.  This  means  that  distinct  pairs  of  ATM 
systems  can  communicate  at  full  wire  speed  with  each  other 
(if  the  switch  has  enough  switching  capacity).  A  switch  can  be 
equipped  with  different  types  (speeds)  of  ATM  ports;  this  way 
a  server  on  ATM  can  have  a  faster  connection  to  the  ATM 
network  than  its  clients. 

Before  data  can  be  transported,  a  Virtual  Circuit  (VC)  has  to 
be  established  between  the  two  end-points  that  wish  to 
communicate  (ATM  is  connection-oriented).  An  application 
can  negotiate  a  QoS  required  for  its  VC.  An  ATM  system 


Figure  I  ATM  as  a  control  and  message  network 


typically  may  use  up  to  several  thousands  of  Virtual  Circuits 
simultaneously  to  different  other  ATM  systems. 

ATM  supports  four  classes  of  traffic.  Ordered  in  a  decreasing 
priority  the  traffic  classes  are: 

Class  A  Constant  Bit  Rate  (CBR),  connection-oriented, 

synchronous  traffic  (uncompressed  voice  or  video) 
Class  B  Variable  Bit  Rate  (VBR),  connection-oriented, 
synchronous  traffic  (compressed  voice  or  video) 
Class  C  Variable  Bit  Rate  (VBR),  connection-oriented, 
asynchronous  traffic  (X.25,  Frame  Relay) 

Class  D  Available  Bit  Rate  (ABR),  connectionless,  packet 
data  (LAN  traffic) 

ATM  is  scaleable  regarding  both  bandwidth  and  topology. 
Speeds  are  supported  from  2  Megabits  up  to  several  Gigabits 
per  second.  ATM  is  often  run  over  a  physical  layer  consisting 
of  one  of  the  standards  from  the  SDH  hierarchy  of  optical 


standards.  The  hierarchy  ranges  from  STM-1  (155,52  Mbps) 
up  to  STM- 16  (2.4  Gbps)  while  even  faster  standards  are 
being  developed. 

ATM  is  suitable  in  LAN  as  well  as  in  WAN  environments. 
LAN  and  WAN  connections  differ  regarding  available 
bandwidth.  That  is  why  congestion  and  flow  control  are 
important  issues  in  large  ATM  networks.  The  ATM  Forum 
and  the  ITU-T  (former  CCITT)  are  currently  working  on 
standards  to  address  these  issues. 

4.2  The  model  and  its  traffic 

Figure  1  shows  schematically  how  an  ATM  network  can  be 
used  as  the  control  and  message  network  for  the  OSM. 

The  functional  area  that  is  modelled  contains  6  modules  that 
are  all  connected  to  both  the  OSM  network  via  optical  links 
and  the  CMN  network  (in  this  case  implemented  by  an  ATM 
network)  via  an  ATM  network  interface  to  which  an  optical  or 
electric  link  is  attached.  The  OSM  controller  (LCE)  is  also 
connected  to  the  CMN  network. 

Note  that  in  this  set-up,  modules  can  not  only  communicate 
with  the  LCE,  but  also  directly  with  each  other  by  using  a 
direct  ATM  virtual  circuit  between  them  without  bothering  the 
LCE. 

Four  kinds  of  traffic  will  be  simulated  in  the  model.  These 
will  be  explained  in  the  following  sections. 

4.2. 1  Commands  between  modules  and  LCE 
Each  module  can  issue  commands  to  the  LCE  to  set  up  or  tear 
down  an  OSM  connection  with  other  modules.  The  time 
between  the  transmission  of  the  request  and  the  moment  at 
which  transmission  of  data  on  the  OSM  connection  can  start, 
is  called  the  link  time.  For  the  so-called  unlink  time  (for 
tearing  down  a  connection)  a  similar  definition  is  valid.  A 
driving  requirement  was  that  the  (un)link  time  had  to  be  less 
than  50  ps. 

Several  high-level  protocols  have  been  considered  for 
accomplishing  a  reliable  connection  set-up.  To  minimise  the 
link  time,  the  protocol  in  Figure  2  was  chosen.  The  protocol 
works  the  following  way; 

Suppose  module  A  wants  to  set  up  an  OSM  connection  with 
module  B.  Module  A  sends  a  connection  request  to  the  LCE. 
After  receiving  the  request,  the  LCE  checks  whether  module  B 
is  available  for  the  requested  connection.  If  not,  the  LCE 
sends  a  negative  response  to  module  A.  If  module  B  is 
available,  the  LCE  sends  a  message  to  module  B  to  inform 
about  the  OSM  connection  that  is  about  to  be  activated.  At  the 
same  time  the  LCE  sends  a  positive  response  to  module  A  and 
starts  setting  up  the  OSM  connection.  When  module  B 
receives  the  message  from  the  LCE,  it  sends  a  (positive) 
acknowledgement  to  module  A.  When  module  A  has  received 
positive  messages  from  both  the  LCE  and  module  B,  it  may 
start  transmitting  data  via  the  OSM  connection. 


Figure  2  OSM-command  Protocol 
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For  the  simulation  it  has  been  assumed  that  3  modules 
maintain  the  same,  static  OSM  connection  configuration  (e.g. 
continuous  high  bandwidth  demanding  sensor  processing). 

The  remaining  3  modules  are  resources  for  which  is  competed. 
They  randomly  issue  OSM-commands.  These  requests  are 
exponentially  distributed  with  a  mean  of  10  Hz.  In  a  real 
network  the  mean  OSM-command  release  rate  is  probably 
lower  than  10  Hz.  Because  the  link  time  of  an  OSM- 
connection  is  only  worthwhile  when  relatively  large  amounts 
of  data  have  to  be  transported.  The  message  length  is  25  B 
(fits  into  1  ATM  cell).  Because  of  the  need  to  minimise  the 
link  time,  this  traffic  is  assigned  to  the  VBR  traffic  class  and 
not  to  the  low  priority  ABR  class.. 

4.2.2  Status  (synchronisation)  traffic 

It  is  assumed  that  each  module  periodically  sends 
synchronisation  or  status  data  to  the  LCE  for  configuration 
management  purposes.  These  are  small  messages  (25  B)  that 
fit  into  1  ATM  cell.  They  are  generated  with  a  triangular 
distribution  with  a  mean  of  1  ms  (1000  Hz),  a  minimum  of  0.8 
ms  and  a  maximum  of  1 .2  ms.  This  traffic  is  assigned  to  the 
ATM  ABR  traffic  class. 

4.2.3  Control/data  traffic  between  modules 
Applications  use  a  higher  layer  protocol  to  synchronise  their 
activities  and  to  exchange  information.  This  dynamic 
behaviour  depends  on  the  functionality  and  implementation  of 
the  modules.  The  dynamic  behaviour  is  modelled  by  the 
following  random  parameters: 

•  message  size; 

•  transmission  interval; 

•  source  module; 

•  destination  module. 

The  size  of  the  messages  is  uniformly  distributed  between  1 
kB  and  16  kB.  The  messages  are  generated  with  an 
exponential  distribution  with  a  mean  of  5  ms  (200  Hz).  The 
source  and  destination  modules  are  chosen  according  to  a 
uniform  distribution.  This  traffic  uses  the  ATM  ABR  traffic 
class. 

4.2.4  File  transfer  traffic  between  modules 

Modules  can  exchange  certain  amounts  of  data  for  which  it  is 
not  effective  to  request  an  OSM  connection  or  when  the 
desired  OSM  connection  is  unavailable.  This  data  can  be 
transported  by  means  of  a  file  transfer  using  the  CMN.  This 
results  in  a  burst  of  maximum  sized  packets  between  two 
modules.  The  dynamic  behaviour  is  modelled  by  the 
following  random  parameters: 

•  message  burst  size; 

•  source  module; 

•  destination  module. 

The  modules  are  chosen  according  to  a  uniform  distribution, 
just  like  the  file-size  (between  64  kB  and  192  kB).  A  file  burst 
is  generated  every  0.1  s  (10  Hz)  and  is  assigned  to  the  ATM 
ABR  traffic  class. 


4.3  Abstractions  and  limitations  of  the  model 
This  section  describes  limitations  and  abstractions  of  the 
model  when  compared  to  a  possible  real  world 
implementation. 

1 .  Only  Permanent  V'Cs  are  used  in  the  model. 

The  process  of  dynamically  (on  demand)  setting  up 
an  SVC  (Switched  VC)  can  take  milliseconds  in  a 
real  ATM  network.  In  the  avionics  system  being 
modelled,  such  a  delay  is  intolerable.  Hence,  it  is 
assumed  only  PVCs  (Permanent  VC)  are  used.  In  a 
real  implementation  these  can  be  set  up 
automatically  during  system  initialisation.  As  a 
consequence  an  ATM  node  can  start  transmitting 
data  immediately;  it  is  not  necessary  to  set  up  a  VC 
first. 

2.  All  links  have  the  same  bandwidth. 

In  an  ATM  network  it  is  possible  for  a  node  that  will 
receive/transmit  more  data  than  other  nodes  to  have 
a  higher  capacity  network-connection.  Since  in  the 
model  the  traffic  is  fairly  well  distributed,  an 
optimisation  like  this  is  not  used.  Simulations  are 
run  for  ATM  networks  based  on  SDH  STM-1  and 
SDH  STM-4. 

3.  Physical  layer  overhead  not  modelled  properly. 

In  an  ATM  network  based  on  SDH  there  is  some 
overhead  at  the  physical  layer.  On  an  STM-1 
(155.52  Mbps)  trunk  every  27th  cell  is  needed  for 
that  overhead  limiting  the  available  bandwidth  to 
149.76  Mbps.  This  is  modelled  assigning  an  overall 
available  bandwidth  of  149.76  Mbps  to  the  ATM 
trunks;  in  stead  of  reserving  every  27th  cell.  For 
STM-4  (622.08  Mbps)  every  108th  cell  is  not 
available,  resulting  in  an  available  bandwidth  of 
616.32  Mbps. 

4.  ATM  interface  processing  overhead  not  modelled. 

Of  course,  some  processing  needs  to  be  performed  at 
an  ATM  interface.  ATM  Adaptation  Layer  (AAL) 
headers/trailers  must  be  added  or  removed.  Packets 
of  data  have  to  be  segmented/reassembled  to/from 
cells.  In  state-of-the-art  ATM  adapters  dedicated 
hardware  is  used  to  obtain  a  minimum  latency  (64 
bit  RISC  processors,  DMA,  etc.).  Data  is  transferred 
from/to  the  host  memory  while  the  cells  of  a  packet 
are  being  transmitted/received  to/from  the  ATM  net¬ 
work.  Latency  introduced  by  a  carefully  designed 
ATM  adapter  is  small  when  compared  to  the  total 
latency  of  transferring  a  message  through  the  ATM 
network. 

5.  Higher  layer  protocols  are  not  modelled. 

The  objective  of  the  simulation  was  to  focus  on  the 
ATM  level  of  the  CMN.  Because  of  this,  no  higher 
layer  protocols  have  been  modelled.  As  a 
consequence  no  higher  layer  protocol  headers  have 
been  taken  into  account  when  decreasing  the 
maximum  packet  size  during  consecutive  simulation 
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runs.  As  another,  more  serious  consequence,  no  flow 
control  is  available.  This  means  that  all  data  for  a 
file  transfer  enters  the  ATM-interface  of  a  module  as 
maximum-sized  packets  simultaneously. 

6.  VC  and  their  QoS  parameters  are  not  modelled. 

In  a  real  ATM  network  all  data  offered  to  an  ATM 
network  interface  must  be  transmitted  on  a  pre- 
established  VC  while  respecting  the  QoS  parameters 
that  were  agreed  upon  during  the  VC  set-up  ('traffic 
shaping').  The  ATM  model  did  not  have  options  to 
specify  other  QoS  parameters  than  the  ATM  traffic 
class.  All  data  offered  to  an  ATM  network  interface 
is  transmitted  as  fast  as  possible  (at  the  speed  of  the 
trunk  connected  to  it).  This  is  slightly  worse  than  in 
the  real  world  and  increases  the  probability  of  cell 
loss  in  the  switch. 

7.  Packet  transmission  is  considered  im-interruptable. 
It  is  desirable  that  the  transmission  of  a  (possibly 
large)  low  priority  packet  (e.g.  ABR)  is  interrupted 
because  a  higher  priority  message  (e.g.  VBR)  is 
offered  for  transmission  to  the  ATM  interface. 
Depending  on  the  implementation  of  an  ATM 
adapter  and  whether  (and  in  what  way)  it  enforces 
traffic  shaping;  this  may  be  possible  in  a  real  ATM 
adapter.  It  is  not  included  in  the  model.  As  a  result 
the  latency  of  high  priority  messages  depends  on  the 
maximum  packet  size  for  lower  priority  messages. 

4.4  Short  description  of  the  simulation  environment 

SES/Workbench  is  a  graphically  oriented  general-purpose 
simulation  language  that  contains  features  for  modelling 
computer  systems  and  communication  networks.  The 
graphical  interface  allows  users  to  build  and  represent  designs 
pictorially.  The  major  building  blocks  are: 

•  Nodes 

•  Arcs 

•  Transactions 

There  four  basic  types  of  nodes: 

Resource  management  nodes 

Resource  management  nodes  create,  allocate  and  release  the 
resources  used  by  transactions.  The  resources  may  be 
processors,  memory,  communication  links,  busses  and  system 
processes. 

Transaction  flow  control  nodes 

Transaction  flow  control  nodes  create,  destroy,  and  alter  flow 
of  transactions  through  the  system. 

Sub-model  management  nodes 

Sub-model  management  nodes  allow  a  model  to  be  developed 
and  specified  as  a  hierarchical  collection  of  sub-models. 

Miscellaneous  nodes 
Such  as,  user-defined  nodes. 


A  collection  of  building  blocks  represents  system  components, 
processors,  resources,  transaction  flows,  and  others.  To  build  a 
model  one  defines  a  transaction  that  corresponds  to  a  message. 
After  that,  a  directed  graph  consisting  of  nodes  and  arcs  is 
created.  This  is  done  by  placing  icons  on  the  display  that  can 
be  connected  by  arcs.  The  arcs  and  nodes  describe  how 
transactions  flow  through  the  model.  In  this  way  it  is  easy  to 
create  and  view  complex  models. 

SES/Workbench  provides  real-time  animation  that  displays 
transactions  flowing  through  the  model  and  shows  events  that 
occur  at  nodes.  Simulation  results  can  be  displayed  in  both 
numerical  and  graphical  formats,  either  during  the  simulation 
or  after  it  has  been  completed. 

Several  statistical  functions,  built-in  probability  density 
functions,  and  queuing  disciplines  are  available. 

5  EXPERIMENTS 

5.1  Measurements 

For  the  experiments  the  following  statistics  were  measured: 

•  mean  ATM-utilisation  for: 

•  network  interfaces/links; 

•  the  ATM-switch; 

•  ATM-switch  lost-cells; 

•  mean  OSM-command  response-time  (including 
acknowledgements); 

•  mean  status-message  response-time  (including 
acknowledgements); 

•  mean  file-burst  response-time  (including 
acknowledgements). 

5.2  Parameters 

To  investigate  the  model,  the  following  parameters  were 
varied: 

•  ATM-bandwidth  149  Mbps,  616  Mbps 

•  Workload  nominal,  high  (5  times  nominal) 

•  Maximum  packet-  100%,  40%,  12.5%,  6.25%  of 

size  control/data  traffic  and  file-burst 

maximum  packet-size 

ATM-bandwidth  and  workload  parameters  were  used  to  vary 
the  traffic  and  stress  of  the  ATM-network.  The  nominal 
workload  described  in  section  4.2  results  in  a  mean  control 
and  data  traffic  load  of  13.67  Mbps  and  a  mean  file-burst  load 
of  10  Mbps.  The  high  workload  approximately  produces  5 
times  more  traffic  than  the  nominal  workload:  a  mean 
control/data  traffic  load  of  68.36  Mbps  and  a  mean  file-burst 
load  of  50  Mbps.  The  high  load  control/data  traffic  is  created 
by  increasing  the  release-rate.  The  distribution  in  time  of  the 
extra  packets  is  uniformly.  The  high  load  file-burst  is  created 
by  increasing  the  range,  from  which  the  size  of  the  file-burst  is 
uniformly  chosen,  from  [64  kB,  192  kB]  to  [320  kB,  960  kB]. 
The  resulting  extra  file-burst  traffic  enters  the  network 
simultaneously. 
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As  explained  in  sections  4.2  and  4.3,  the  larger  the  allowed 
packet-sizes,  the  higher  the  latencies  of  messages  can  become. 
For  this  reason,  the  maximum  packet-size  is  varied  during  the 
experiments.  For  file-burst  messages  a  smaller  packet-size  will 
result  in  more  (but  smaller)  packets  being  generated 
simultaneously.  The  model  does  not  include  the  effect  of 
additional  overhead  needed  to  reassemble  messages  from 
multiple  smaller  packets.  The  OSM-commands  and  status- 
messages  are  not  varied.  As  described  in  section  0  and  4.2.2 
they  always  occupy  1  ATM  cell. 

5.3  Experiments 

The  following  groups  of  experiments  will  be  described: 

•  Reference  experiments  with  single  messages; 

•  experiments  with  an  ATM-bandwidth  of  149  Mbps  during 
nominal  operation; 

•  experiments  with  an  ATM-bandwidlh  of  616  during 
nominal  operation  and  operation  under  high  loads. 

All  results  are  mean  values  over  the  complete  simulation 
period  and  times  are  reported  in  ps. 

5.3.1  Reference  experiments 

The  response-times  of  an  OSM-command  message,  a  single¬ 
cell  status-message  and  file-burst  messages  were  determined, 
while  no  other  messages  were  in  the  network.  Note  that  all 
measured  response-times  include  the  latencies  of 
acknowledgements  being  sent  back  to  the  source  of  the 
original  messages.  The  service  times  in  the  involved  modules 
and  LCE  were  fixed  to  their  mean  service  times  (10  ps). 


149  Mbps  ATM 

616  Mbps  ATM 

Status-message 

33.2 

15.6 

OSM-command 

54.8 

28.4 

64  kB  file-burst 

3900 

955 

640  kB  file-burst 

42600 

10400 

The  single-cell  status-message  response-time  includes  the 
following  latencies; 

•  Four  cell  transmissions  (message  and  acknowledgement) 
from  the  network  interface  to  the  ATM-switch  and  vice 
versa.  This  is  the  time  needed  to  put  bits  of  a  cell  on  a 
link. 

•  Four  link  propagation-delays  (2  for  the  message  and  2  for 
the  acknowledgement)  from  the  source  network  interface 
to  the  ATM-switch  and  from  the  ATM-switch  to  the 
destination  network  interface.  For  the  experiments  all 
links  had  a  length  of  1  meter. 

•  Two  switch  delays  (message  and  acknowledgement).  This 
is  the  time  to  move  the  cell  through  the  switch-fabric  from 
the  input  port  to  the  output  port. 

•  One  service  time  (10  ps)  needed  in  the  destination  module 
to  produce  the  acknowledgement. 

The  table  shows  that  the  50  ps  OSM  (un)link-time 
requirement  cannot  be  achieved  with  the  149  Mbps  ATM- 
bandwidth. 


5.3.2  149  Mbps  experiment 

Description: 

OSM-command,  status-message  and  file-burst  mean 
response-times,  during  nominal  load,  149  Mbps 
ATM,  a  20  second  simulated  time  and  triangular 
distributed  services  times  for  modules  and  the  LCE 
with  a  minimum  of  5  ps,  a  mean  of  10  ps  and  a 
maximum  of  15  ps. 

Parameters: 

packet-size  (in  percentages). 

Results: 


Size 

OSM-command 

Status 

File-burst 

100 

147.6 

167.2 

14678 

40 

81.4 

125.4 

9674 

12.5 

66.5 

101.5 

8408 

6.25 

59.1 

89.9 

8507 

Figure  3  shows  the  measured  response  times  of  the  OSM- 
commands  and  status  messages  with  the  ATM  network 
opating  at  149  Mbps  and  with  a  nominal  workload. 

Conclusions  from  the  measurements; 

•  smaller  packet  sizes  reduce  the  response-times; 

•  the  improvement  of  the  mean  file-burst  response-time  with 
smaller  packet-sizes  is  because  of  a  decrease  in  packet-size 
of  the  control/data  traffic.  This  decrease  causes  the 
control/data  traffic  load  to  be  more  uniformly  distributed 
in  the  functional  area  (space)  and  in  time; 

The  mean  OSM-command  response  time  during  high  load, 

149  Mbps  ATM  with  100%  packet  size  was  400  ps.  (Because 
this  result  is  far  from  the  desired  50  ps,  further  experiments 
were  concentrated  on  616  Mbps  ATM-bandwidth 
experiments.) 


The  following  ATM-network  statistics  were  measured: 


Utilisation  of: 

Nominal  load 

High  load 

ATM  switch 

1.5% 

6.2% 

Module  Net  Interface 

3.6% 

15.5% 

LCE  link 

1.8% 

1 .8% 

The  experiments  showed  that  when  occurrences  of  file-bursts 
overlap  in  time  and  space  (to  the  same  destination-module), 
cell-loss  can  occur  even  during  nominal  load.  (In  such  a  case 
the  ATM-switch  output  buffer  to  the  involved  destination- 
module  is  easily  congested.) 

5.3.3  616  Mbps  experiments 

Description: 

OSM-command,  status-message  and  file-burst  mean 
response-times,  during  nominal  and  high  load,  616 
Mbps  ATM,  a  20  second  of  simulated  time  and 
triangular  distributed  services  times  for  modules  and 
the  LCE  with  a  minimum  of  5  ps,  a  mean  of  10  ps 
and  a  maximum  of  15  ps. 

Parameters: 

packet-size  (in  percentages); 


load  (nominal  or  high). 

Results: 

Nominal  load; 


Size 

OSM-command 

Status 

File-burst 

100 

36.2 

23.8 

2863 

40 

29.0 

20.5 

2367 

12.5 

29.2 

19.9 

2069 

6.25 

28.5 

19.5 

2024 

Figure  4  shows  the  measured  response  times  of  the  OSM- 
commands  and  status  messages  with  the  ATM  network 
opating  at  616  Mbps  and  with  a  nominal  workload. 


High  load: 


Size 

OSM-command 

Status 

File-burst 

100 

50.2 

150.5 

12018 

40 

39.9 

91,9 

9911 

12.5 

32.6 

150.6 

12482 

6.25 

30.7 

101.5 

11109 

Figure  5  shows  the  measured  response  times  of  the  OSM- 
commands  and  status  messages  with  the  ATM  network 
opating  at  149  Mbps  and  with  a  high  workload. 

Conclusions  from  the  measurements: 

•  With  the  high  load,  94%  of  the  OSM-commands  are 
processed  within  50  ps.  (This  statistic  is  not  shown  in  the 
tables). 

•  With  the  nominal  load  the  packet  size  has  only  minor 
influence  on  the  response-times,  because  packets  that 
block  the  network  interface  of  a  sending  module  (or  the 
ATM-switch)  for  packets  that  follow,  are  served  4  times 
faster  in  the  ATM-network  than  during  the  149  Mbps 
experiments; 

•  The  irregular  shape  of  the  graph  of  the  high  load  file-burst 
response-time  may  be  caused  by  file  bursts  that  overlap  in 
time  and/or  space.  One  of  the  following  scenarios  might 
have  occurred: 

1 .  Bursts  overlap  in  time  and  are  transmitted  from 
the  same  module.  Because  all  bursts  have  the 
same  priority,  the  second  burst  is  delayed  until 
the  first  burst  has  been  transmitted; 

2.  Bursts  overlap  in  time  and  are  transmitted  from 
different  modules,  but  to  the  same  module.  This 
causes  both  extra  delays  and  cell-loss  in  the 
ATM-switch.  During  the  experiments  with 
nominal  load,  almost  no  cell-loss  occurred. 

Because  of  the  relatively  short  simulated  time  of  20  seconds 
an  occurrence  of  one  of  these  scenarios  has  a  large  impact  on 
the  shape  of  the  graph,  Inspection  of  the  collected  statistics 
showed  that  the  experiments  that  were  responsible  for  the 
peaks  in  the  high  load  graphs  suffered  from  severe  cell-loss 
when  compared  to  the  other  experiments  in  the  same  graph. 
This  may  indicate  that  scenario  (2)  is  responsible. 

•  The  irregular  shape  of  the  graph  of  the  high  load  status- 
message  experiments  is  similar  to  the  shape  of  the  high 
load  file-burst  experiments.  The  status-messages  suffer 
from  the  file  bursts  the  most,  because  status  messages 
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have  the  same  priority  as  file  bursts,  while  the  OSM- 
commands  have  a  higher  priority. 


The  following  ATM-network  statistics  were  measured: 


Utilization  of: 

Nominal  load 

High  load 

ATM  switch 

0.4% 

1.5% 

Module  Net  Interface 

0.9% 

4.0% 

LCE  link 

0.4% 

0.4% 

6  CONCLUSIONS  AND  RECOMMENDATIONS 

From  the  simulation  experiments  the  following  can  be 

concluded. 

1 .  During  high  load  with  a  maximum  packet-size  of  64  kB, 
94%  of  the  OSM-commands  (link  or  unlink  commands) 
are  processed  within  50  ps  when: 

•  at  least  a  616  Mbps  bandwidth  is  used  for  the 
ATM-links  and  network  interfaces; 

•  an  ATM-switch  is  used  with  a  9.861 12  Gbps 
aggregate  bandwidth,  with  a  typical  switch 
fabric  latency  of  about  5  ps; 

•  the  module  and  LCE  service  times  approximate 
a  triangular  distribution  with  a  minimum, 
maximum  and  mean  of  respectively  5  ps,  15  ps, 
and  10  ps; 

•  OSM-commands  have  priority  over  other 
packets  in  the  ATM  network  interface  and  other 
cells  in  the  ATM-switch. 

2.  Because  the  status  traffic  introduces  only  minor  workload 
(thus  minor  latency  for  lower  priority  messages)  and  it  is 
important  that  status-messages  have  a  low  latency,  it  is 
recommended  that  these  messages  have  a  high  ATM- 
priority  like  the  OSM-commands. 

3.  It  is  recommended  that  both  the  ATM  network  interfaces 
and  the  ATM-switch  have  separate  output-buffers  for  cells 
with  different  priorities  to  make  the  latency  of  high 
priority  messages  independent  of  the  packet-size  of  lower 
priority  messages. 

4.  Traffic-bursts  such  as  simulated  in  the  model  should  be 
suppressed  or  controlled  to  prevent: 

•  that  the  network  interface  of  a  module  is  blocked  for 
other  traffic; 

•  that  the  packets  of  a  burst  are  transmitted  one-after- 
the-other  without  gaps,  causing  severe  load-peaks. 
For  this  purpose  higher  layer  protocols  could  be 
used,  that  apply  flow  control,  e.g.  sliding-window 
mechanisms,  and  at  the  ATM-layer  Virtual  Circuits 
for  each  traffic-stream  with  properly  configured 
QoS-parameters  to  enforce  traffic  shaping. 

5.  Because  it  is  expected  that  the  bandwidth  of  ATM- 
networks  will  be  increased  significantly  in  the  near  future 
and  because  in  an  ATM-network  different  types  of  data 
can  be  transferred  with  different  QoS,  it  should  be 
considered  to  transfer  the  high  bandwidth  data  via  the 
ATM-network  as  well.  Because  the  OSM  would  no  longer 
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be  necessary,  the  complexity  of  the  avionics  network 
would  be  reduced  significantly. 
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Figure  3  Measured  response  times  with  149  Mbps  ATM  with  Figure  5  Measured  response  times  with  616  Mbps  ATM  with 
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Figure  4  Measured  response  times  with  616  Mbps  ATM  with 
nominal  workload 

Table  1  Data  categories  and  characteristics  _ 


Parameter 

Video 

Fast  sensor 

Medium 

sensor 

Slow  sensor 

Control/data 

Sync 

File  transfer 

Data  rate 

-  applications 

-  frame  length 

-  rate 

2  Gbps 

Video 

25  Mbits 

80  Hz 

2  Gbps 

Radar 

2  Mbits 

1  kHz 

750  Mbps 

Beam  steer 

64  kbits 

10  kHz 

250  Mbps 

E/0  data 

5  Mbits 

50  Hz 

<  1  Mbps 

Various 

32  bits  -  132  kbits 

50  -  200  Hz 

<  1  Mbps 

Various 

<  100  kbits 

50  Hz  -  1  kHz 

<  1  Gbps 

Various 

1  Mbit 

Periodic/aperiodic 

periodic 

periodic 

periodic 

periodic 

both 

periodic 

aperiodic 

Persistence 

10s  of  s 

10s  of  s 

10s  of  s 

10s  of  s 

10s  of  s 

10s  of  s 

message  length 

Latency 

-  bit 

-  frame 

10s  of  ms 

5  ps 

5  ps 

5  ps 

100  ps 

10  ps 

1  ms 

Time  tagging 

no 

yes 

yes 

yes 

- 

- 

no 

Topology 

point/point 

point/point 

point/point 

point/point 

multipoint 

multipoint 

point/point 

Delivery  guarantee 

Bit  errors 

detected 

Bit  errors 

corrected 

Bit  errors 

corrected 

Bit  errors 

corrected 

Frame 

acknowledgemt 

Frame  errors 

corrected 

Frame 

acknowledgment 
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1.  ABSTRACT 

Modern  technological  and  tech¬ 
nical  possibilities  of  multifunc¬ 
tional,  fault-tolerant  radio  sys¬ 
tems  for  armed  forces  operations 
are  described. 

With  the  availability  of  new  tech¬ 
nologies  it  appears  technically 
feasible  to  adjust  the  nationally 
diverse  radio  signal  formats  in 
multinational  operations  and  to 
exchange  them  internationally 
without  compromising  any  se¬ 
curity  interests  of  the  operating 
forces.  The  central  technical  pa¬ 
rameters  of  the  participating  na¬ 
tions'  radio  functions  need  to  be 
exchanged  for  this  purpose. 

However,  such  parameter  ex¬ 
change  does  not  restrict  the  use 
of  nationally  defined  waveforms. 
Due  to  present  capabilities,  the 
simultaneous  use  of  radio  func¬ 
tions  on  a  national  and  multina¬ 
tional  basis  is  possible  for  coop¬ 
erating  forces  and,  due  to  the 
expected  benefits,  ought  to  be 
recommended. 


Command  distribution  via  both 
national  communication  chan¬ 
nels  and  multinational  fast  com¬ 
munication  channels  permits  na¬ 
tionally  supported  multinational 
command  structures.  A  unique 
way  to  achieve  different  national 
COMSEC  codes  will  be  derived 
from  so-called  c*)  Codes.  The  c 
code  can  be  transmitted  via  na¬ 
tional  and  multinational  protected 
channels  without  any  loss  of  se¬ 
curity. 

Armed  forces  require  a  new, 
additional  possibility  of  operating 
with  multifunctional  radio  sys¬ 
tems  in  missions  with  high  se¬ 
curity  requirements  for  the  com¬ 
munication  equipments.  During 
mission  preparation,  the  ECCM 
measures  for  the  communication 
systems  are  designed  especially 
for  the  mission.  Such  radio 
waveforms  tailored  for  a  specific 
mission  will  result  in  greater 
protection  compared  with  gen¬ 
erally  defined  radio  waveforms, 
which  are  partially  known  world¬ 
wide,  without  losing  the  possibil¬ 
ity  of  cooperating  with  other  par¬ 
ticipating  forces,  by  using  ex¬ 
changeable  waveforms  for  these 
communication  links. 


2.  INTRODUCTION 

The  new,  international  doctrine 
assumes  that  the  classical  con¬ 
frontation  of  East-West  is 
brought  to  an  end.  This  new  per¬ 
ception  forsters  a  new  way  of 
cooperation,  where  time  and 
area  play  an  important  factor, 
and  the  purpose  of  the  military 
power  appears  to  be  changed. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
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sometimes  to  humanitarian  aids  3. 
objective.  NATO  and  remaining 
CSCE  states  collaborate  in  new 
missions  such  as  peace  keeping 
and  peace  enforcing,  and  a 
regional  conception  is  about  to 
emerge.  This  new  attitude 

requires  a  completely  different 
understanding  of  interoperability 
and  of  communication  for  armed 
forces  missions.  Whereas,  in  the 
past,  interoperability  of  weapon 
systems  appeared  to  be 

required,  the  new  doctrine 

emphasizes  an  improved  com¬ 
munication  interoperability.  It  is 
via  communication  that  forces 
from  different  nations  can  be  co¬ 
ordinated,  and  time-dependent 

coalitions  for  specific  tasks  can 
be  achieved  provided  a  political 
mandate  is  given. 

Radio  systems  are  used  by  the 
military  for  the  following  three 
purposes:  3.1 

•  communication, 

•  navigation, 

•  identification. 

Common  to  these  functions  is 
the  transport 

•  of  information  (with  communi¬ 
cation) 

•  of  means  (with  navigation) 

•  of  situation  (with  identification) 
via  a  suitable  structured  radio 
waveform.  The  manipulation  of 
radio  waves  determines  the 
system  architecture  and  its  in¬ 
herent  characteristics. 

New  military  equipment  open  the 
way,  in  association  with  the 
existing  technical  structures,  that 
a  multinational  interoperability 
mission  via  support  of  adequate 
radio  systems  appears  possible. 
However,  at  present,  necessary 
procedures  do  not  yet  exist. 


PRESENT TECHNOI  OCY 

Today's  military  radio  systems 
contain  many  different  radio 
tasks  for  communication,  navi¬ 
gation  and  identification.  Radio 
functions,  like  VHF/UHF,  JTIDS/ 
MIDS,  GPS,  NIS,  and  SATCOM 
are  handled  by  an  individual 
equipment  often  consisting  of 
various  LRUs.  Without  a  built-in 
redundancy,  failure  of  a  single 
LRU  can  result  in  a  failure  of  a 
radio  function.  In  the  future,  in¬ 
dividual  radio  functions  need  to 
be  integrated  as  a  modular  sys¬ 
tem  concept  with  software-con¬ 
trolled  radio  functions. 

New  technology  for  military  ra¬ 
dios  will  be  based  on  an  equip¬ 
ment  architecture  of  a  single  ra¬ 
dio  in  which  all  radio  functions 
are  determined  by  adequate 
software  algorithms. 

System  Architecture 
In  principle,  the  new  architecture 
for  a  Multirole  Multifunctional 
Modular  Radio  (M3R)  consists  of 
the  following  five  modules; 

•  Antenna  System, 

•  Transmitter  /  Receiver, 

•  Pre-Signal  Processor, 

•  Data  Processor, 

•  Man-Machine  Interface  (MMI). 
A  suitable  architecture  for  radio 
systems  based  on  these  mo¬ 
dules  is  shown  in  the  attached 
Figure  1 . 
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3.2  Allocation  of  Functions 

The  main  functions  of  a  Multirole 
Multifunctional  Modular  Radio 
system  are  allocated  to  the 
above  modules  as  follows; 


3.2.1  Antenna  System  Module 

The  antenna  system  module 
comprises  the  following  ele¬ 
ments: 

•  Antenna  switching 

•  Matching 

•  NEMP  protection 

•  Transmit/receive  switch 

For  tactical  M3R,  an  antenna  in 
a  suitable  frequency  range  of  30 
to  88  MHz  (HF),  of  118  to  156 
MHz  (VHF)  and  225  to  400  MHz 
(UHF)  is  required.  In  view  of  the 
different  waveforms,  antennas 
with  omnidirectional  pattern  are 
preferably  used. 


3.2.2  Transmitter  /  Receiver  Module 

The  Transmitter/Receiver(T/R) 
module  has  three  functions: 

•  transmitting, 

•  receiving, 

•  synthesizing 

for  processing  mainly  analog 
signals. 

The  following  four  main  parame¬ 
ters  have  to  be  changed  in  the 
new  transmitter/receiver  module 
to  acchieve  various  radio  wave¬ 
forms  necessary  for  communica¬ 
tion  interoperability: 

•  frequency  range, 

•  filter  bandwidths, 

•  modulation  mode  and 

•  hop  rate. 


3.2.2. 1  Transmitter 

The  transmitter  amplifies  the 
modulated  RF  signal  (supplied 


by  frequency  synthesizer)  to  the 
required  transmitter  power  and 
applies  the  transmit  signal  to  the 
antenna  system. 

The  implementation  of  different 
waveforms  in  the  transmitter 
does  not  only  require  different 
frequency  ranges  but  also  a 
waveform-specific  implementa¬ 
tion  of  the  standardized  time 
functions  for  transmitter  keying  in 
hopping  mode  (time  constants: 
dwell  rise  time,  dwell  fall  time, 
etc). 

The  transmitter  comprises  the 
following  elements: 

•  RF  amplifier  and  RF  band¬ 
pass  filter  (e.g.  for  PSK  mode) 

•  Amplitude  modulator 

•  Power  amplifier 

•  Harmonics  filter 

•  Collocation  filter 

•  Transmitter  keying  in  fre¬ 
quency  hopping  mode 


3. 2. 2. 2  Receiver 

The  receiver  converts  the  RF 
signal  picked  up  by  the  antenna 
into  an  IF  signal.  The  receiver 
comprises  the  following  ele¬ 
ments: 

•  Input  filter 

•  Preamplification 

•  Multistage  frequency  conver¬ 
sion 

•  Multistage  IF  signal  process¬ 
ing 

•  Generation  of  a  digitized  IF 
signal 

•  Automatic  gain  control  (AGC) 


3. 2. 2. 3  Synthesizer 

In  transmission  mode,  the  fre¬ 
quency  synthesizer  supplies  the 
frequency-modulated  RF  signal 
to  the  transmitter,  whereas  in  re- 
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ceive  mode  it  supplies  the  con¬ 
version  signal  to  the  receiver. 

The  various  radio  waveforms 
differ  in  the  synthesizer  in  the 
hop  rate  (transient  times),  fre¬ 
quency  ranges,  modulation 
methods  and  specific  filtering  of 
the  baseband  signal  to  be 
transmitted. 


3.2.3  Pre-Signal  Processor  Module 

The  main  task  of  the  digital  sig¬ 
nal  processor  module  is  to  de¬ 
modulate  the  received  signal  and 
to  process  the  demodulated  sig¬ 
nal  for  the  data  processing,  i.e. 
amplitude-  and  time-regenerated 
data  streams  for  further  process¬ 
ing  by  the  subsequent  data 
processor  are  available  at  the 
output  of  the  pre-signal  proces¬ 
sor  for  all  waveforms. 

The  distribution  of  the  functions 
between  the  "digital  pre-signal 
processor"  and  the  "data  proces¬ 
sor"  may  vary  according  to  the 
waveform  under  observation. 
One  of  the  criteria  is  the  required 
or  available  computing  power  of 
the  processor  and  another  one 
the  complex  relationship  be¬ 
tween  the  regenerated  baseband 
data  and  the  waveform-specific 
TRANSEC  algorithms. 


3.2.4  Data  Processor  Module 

The  Data  Processor  Module 
comprises  all  functions  required 
for  successful  interoperability  of 
radio  communication.  These 
functions  may  include  -  among 
others  -  TRANSEC  processing 
and  time  management.  The 
digital  processing  functions  are 
mainly  implemented  at  the  useful 
data  rate  (i.e.  16  kbit/s)  and  at 
the  radio  bit  rate  (i.e.  25  kbit/s). 


The  following  functions  are  im¬ 
plemented  in  the  data  processor; 

•  Operating  mode  control 

•  Radio  monitoring 

•  Call  management 

•  Call  acquisition 

•  Net  management 

•  Time  management 

•  Clock  generation 

•  TRANSEC  processing 

•  Frequency  management 

•  Data  transmission  functions 


3.2.5  Man-Machine  Interface  (MMI) 

Within  a  given  basic  architecture, 
the  MMI  comprises  all  interfaces 
to  the  user.  These  include  both 
the  operator  interfaces  (manual 
control  and  load  functions)  and 
the  communication  interfaces 
(voice  and  data). 

The  functions  of  the  MMI  are 
hardly  affected  by  a  waveform 
switch  if  the  useful  data  rates  in 
speech  mode  are  identical  (e.g. 
CVSD  with  16  kbit/s)  and  are  in 
the  same  order  in  the  data 
modes.  Only  the  structures  and 
the  contents  of  the  operating  pa¬ 
rameters  (time,  key,  net  number) 
will  have  waveform-specific 
characteristics. 

The  following  interfaces  will  need 
to  be  implemented: 

•  digital  interface  to  handset, 

•  digital  interface  to  fill  device, 

•  data  interface 


4.  CONSEQUENCES  OF 

PRESENT  TECHNOLOGY 

4.1  Radio  Controllability 

The  presently  used  RF  wave¬ 
forms  are  characterized  via  60  to 
120  technical  parameters  im- 
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plemented  within  the  above  de-  4,2 
scribed  modules.  If 

interoperability  is  needed  for 
missions,  an  exchange  of  radio 
parameters  between  the  various 
armed  forces  will  determine 
whether  various  radio  sets  in  the 
different  radios  will  cope  with  the 
required  communication. 


The  new  technological  capabili¬ 
ties  enable  a  fast  change  of  ra¬ 
dio  function  parameter  in  each 
functional  block  via  software  in¬ 
structions.  In  recent  years,  all 
relevant  radio  parameters  which 
influenced  the  waveforms  were 
analyzed  in  Germany  for  each  of 
the  above  described  modules. 
These  parameters  uniquely 
characterize  all  known  wave¬ 
forms.  Based  on  newest  tech¬ 
nology  trends,  there  are 
approximately  500  qualitative  pa¬ 
rameters  which  characterize  all 
current  radio  waveform.  Recent 
data  processor  modules  allow  a 
predetermination  and  a  continu¬ 
ous  control  of  more  than  500 
well-defined  radio  parameters. 

Figure  2  summarizes  the  alloca¬ 
tion  of  the  radio  parameters  and 
attaches  so-called  module  func¬ 
tions  and  waveform  parameters. 
Figure  3  lists  some  of  those  pa¬ 
rameters  and  provides  a  short 
description  of  the  relevant  pa¬ 
rameters.  Figure  4  summarizes 
typical  values  for  such  parame¬ 
ters  and  provides  information 
where  the  parameters  might 
functionally  be  located. 


Programmability  of  Radio 
System 

The  use  of  such  multifunctional 
radios  does  not  preclude  their 
employment  for  strict  national 
purposes. 

Therefore,  interoperability  of  ra¬ 
dios  is  software-controlled  and 
can  be  programmed  into  the 
data  processor  module  of  inter¬ 
national  partners’  radios,  pro¬ 
vided  an  adequate  data  ex¬ 
change  will  define  actual  pa¬ 
rameters  of  the  radio  waveform 
required.  Thus,  secure  multina¬ 
tional  operations  are  ensured. 

Furthermore,  the  programmabili¬ 
ty  of  all  parameters  for  ECCM 
capabilities  will  improve  the 
flexibility  of  communication 
equipment  for  different  opera¬ 
tions  and  improve  the  ECM  re¬ 
sistance  of  the  troops,  based  on 
the  great  variety  of  possibilities 
of  different  ECCM  actions 
carried  out  during  different  time 
slots. 


Modular  radios  in  the  different 
national  forces  provide  the 
chance  to  exchange  the  essen¬ 
tial  radio  waveform  parameters, 
with  other  nations  and  with  other 
services  for  special  operations, 
and  thus  improve  the  technical 
performance  of  national  com¬ 
munication  systems. 

For  example,  a  software-con¬ 
trolled  radio  set  (Figure  5)  will 
define  required  functions.  The 
radio  functionality  is  achieved  via 


the  individual  personality  part 
which  includes  the  SW  object 
set  (i.e.  pre-defined  SW  pack- 


ages),  switch  settings  etc., 
and 

•  the  physical  characteristics 
inherent  in  the  host  equip¬ 
ment. 

The  advantages  of  software- 
controlled  radios,  namely 

•  multipurpose  communication: 
increased  communication  ca¬ 
pabilities  can  be  applied  in 
different  networks 

•  access:  communication  ac¬ 
cess  is  provided  in  multina¬ 
tional  environment 

•  short  training  cycle:  the  MMI 

can  be  identical  with  present 
radios  4.4 

become  obvious. 

Such  a  radio  system  opens  the 
way  to  a  great  number  of  user 
interfaces  for  military  missions  in 
view  of  formation  of  different  ra¬ 
dio  waveforms. 


Scheme  for  Interoperability 

As  shown  in  Figure  1,  the  control 
of  the  different  waveforms  is  lo¬ 
cated  in  the  RCCS  in  which  the 
radio  waveform  parameters  for  a 
special  waveform  are  stored. 
Such  a  storage  can  be  organized 
in  conjunction  with  c-coded  pa¬ 
rameter  sets.  For  radio  inter¬ 
operability  these  c-coded  pa¬ 
rameters  are  determined  by  the 
nations. 

These  c-coded  waveform  pa¬ 
rameters  (international  parame¬ 
ters)  do  not  influence  the  pa¬ 
rameter  sets  of  nationally  de¬ 
fined  waveforms.  Dependence  of 
the  c-coded  parameters  with 
non-c-coded  parameters  is  im¬ 
possible:  both  parameter  types 
are  strictly  separated. 


The  c-coded  waveform  parame¬ 
ter  can  be  exchanged  by  the 
multinational  mission  planning 
office,  without  the  participating 
nations  jeopardizing  the  security 
of  their  own  national  radio 
waveforms.  The  handling  of  the 
multinational  c-code  should 
multilaterally  be  agreed,  how¬ 
ever.  These  upcoming  agree¬ 
ments  include  the  definition  of 
official  channels  for  c-code  ex¬ 
change.  The  c-code  exchange  is 
the  basis  of  mission  interoper- 
abilty  of  nations'  armed  forces. 


Application  of  Multinational  Ra¬ 
dios 

Many  different  RF  waveforms 
exist  worldwide  today.  A  lot  of 
them  are  also  well-known 
worldwide.  Special  operations  at 
the  national  as  well  as  the  inter¬ 
national  level  may  require  a 
need  to  improve  the  security  of 
RF  waveforms.  For  operations 
with  high  security  requirement 
(Electronic  Counter  Measures) 
the  use  of  multifunctional  radio 
systems  opens  the  way  for  the 
design  of  special  ECCM  capabil¬ 
ity  for  a  pre-defined  mission. 

The  described  military  SW  radio 
for  interoperable  use  opens  the 
way  to  increasing  the  security  of 
the  radio  links  dramatically  for 
special  missions  or  operations. 
Figure  6  shows  the  use  of  RF 
waveforms  during  the  operation 
of  an  airplane  with  different  func¬ 
tional  priorities  for  the  various 
radio  waveforms. 

In  the  case  of  using  multifunc¬ 
tional  radio  equipment,  it  is  pos¬ 
sible  to  adapt  the  radio  wave¬ 
form  in  accordance  to  the  flight 
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requirements,  i.e.  UHF  radio  national  authorities  are  required 

waveform  (Ground  operation)  to  improve  the  current  situation 

and  the  JTIDS  waveform  by  defining  the  necessary  inter- 

(enroute  operation).  national  communication  proce¬ 

dures. 

During  mission  switching  to  a 
new  waveform  is  extremely 
ECM-resistant  and  improves 
communication  security. 


4.5  Points  of  Core  Agreement  for 
interoperable  use  of  multifunc¬ 
tional  Radio  Equipment 

This  technology  of  multifunc¬ 
tional  radios  provides  technical 
means  for  mission  interoperable 
radios  of  various  services  and 
nations. 

Therefore,  the  nations  need  to 
bear  in  mind  that  in  the  long  run 

•  only  radio  systems  interoper¬ 
able  with  or  adaptable  to  the 
c-coded  parameter  require¬ 
ment  should  be  used, 

•  radio  systems  equivalent  to 
the  described  modules  should 
be  integrated  with  mission 
avioncis, 

•  relevant  parameters  should  be 
exchanged  as  early  as 
possible, 

•  such  radio  systems  should  be 
integrated  into  aircraft  oper¬ 
ated  during  joint  missions. 


5.  CONCLUSIONS 


List  of  Abbreviations: 

AGC 

Automatic  Gain  Control 

COMSEC 

Communication  Security 

CPFSK 

Continuous  Phase  Frequency  Shift 
Keying 

CSCE 

Conference  on  Security  and  Co¬ 
operation  in  Europe 

CVSD 

Continous  various  Slope  Delta 
Modulation 

ECCM 

Electronic  Counter  Counter  Measure 

FM 

Frequency  Modulation 

GPS 

Global  Positioning  System 

HW 

Hardware 

IF 

Intermediate  frequency 

JTIDS 

Joint  Tactical  Information  Distribu¬ 
tion  System 

LRU 

Line  Replaceable  Unit 

M3R 

Multimode  Multifunctional  Modular 
Radio 

MIDS 

Multifunctional  Information  Distribu¬ 
tion  System 

MMI 

Man-Machine  Interface 

NATO 

North  Atlantic  Treaty  Organisation 

NEMP 

Nuclear  Electromagnetic  Pulse 

NIS 

NATO  Identification  System 

RCCS 

Radio  control  configuration  system 

RF 

Radio  Frequency 

SATCOM 

Satellite  Communication 

TRANSEC 

Transmission  Security 

UHF 

Ultra  High  Frequency 

VHF 

Very  High  Frequency 

Technical  possibilities  for 
controllable  radios,  in  combina¬ 
tion  with  the  added  c-codes 
waveform  parameters,  will  close 
the  deficiency  of  unavailable 
interoperable  open  radio  sys¬ 
tems  for  secure  multinational 
missions.  Further  actions  by 
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Line 

Name  of  Parameter 

Description 

14 

Audio  Analog  /  Dgital  Conversion 
Clock 

This  parameter  specifies  the  sampling  period  of  the  audio  analog-to-digital  converter  output. 

15 

Audio  Analog  /  Digital  Conversion 
Resolution 

This  parameter  corresponds  to  the  number  of  quantisation  levels  applied  by  an  audio 

analog-to-digital  converter  to  transform  the  received  analogous  signal  value  assigned  to  one  sample  period. 

16 

Audb  Center  Frequency 

Some  HF  data  link  systems  modulate  a  carrier  centered  at  RF  +  x  Hz  where  RF  is  the  HF  frequency 
to  be  used  and  x  the  Audio  Center  Frequency. 

17 

Audio  Input  Level 

This  parameter  defines  the  standard  input  level  at  the  analogue  voice  interface  (e.g.  level  of  miaophone). 

18 

Audio  Output  Frequency  Response 

Set  of  parameters  to  define  the  frequency  response  cf  the  output  signal  at  the  voice  interface  (e.g. 
characteristics  ans  cut-off  frequencies  of  applied  Alter). 

19 

Audio  Output  Level 

This  parameter  defines  the  standard  output  level  at  the  analogue  voice  interface. 

20 

Automatic  Link  Establishment 

The  capability  of  a  radio  station  to  make  contact  or  initiate  a  circuit,  between  itself  and  another  specified 
radio  station,  without  operator  assistance  and  usually  under  processor  control.  Several  techniques  and 
protocols  for  the  Automatic  Link  Establishment  are  in  use  to  implement  this  feature. 

21 

Back  Up 

Space  of  memories  required  in  a  software  controlled  radio  for  fixing  the  functionality  of  the  different 
equipment  parts  to  realize  a  special  waveform. 

22 

Baseband  Pulse  Response 

The  Baseband  Pulse  Response  is  used  to  describe  the  time  continuous  modulation  signal  of  a  digitally 

modulated  waveform.  It  is  usually  defined  as  the  pulse  response  of  a  linear  filter. 

which  receives  the  baseband  symbols  at  its  input  and  transmits  the  modulation  signal  at  its  output. 

Figure  3  :  Short  description  of  selected  radio  parameter 
( some  examples ) 


Line 

Name  of  Parameter 

ISO/OSI 

Antenna 

TX/RX 

Preprop 

Dataprop 

MfVII 

Un-classified  Value 

Radio  1 

Un-classified  Value 

Radio  2 

14 

Audio  Analog  /  Digital  Conversion 
Clock 

1 

1 

■ 

1 

X 

16  kHz 

ECCM  :  14,4  kHz,  AKWand  HW 

Krypto  :  16  kHz 

15 

Audio  Analog  /  Digital  Conversion 
Resolution 

1 

X 

1  bit 

1  bit 

16 

Audio  Center  Frequency 

1 

1 

1 

17 

Audio  Input  Level 

3 

■ 

■ 

X 

0,25  Vrms  @  150  Ohm 

250  mV  @  150  Ohm 

18 

Audio  Output  Frequency  Response 

3 

1 

1 

1 

1 

B 

+/-  3  dB  ripple;  300-3500  Hz 

0,3  ...3,0  kHz 

19 

Audio  Output  Level 

3 

B 

2,75  Vrms  @  150  Ohm 

50  mW  @  600  Ohm,  1  W  @  50  Ohm 

20 

Automatic  Link  Establishment 

1 

1 

1 

B 

1 

21 

Back  Up 

■ 

■ 

■ 

B 

1 

1  Mbit 

22 

Baseband  Pulse  Response 

1 

1 

1 

1 

1 

Continuous  phase 

Raised  cosine 

Figure  4  :  Allocations  of  selected  parameter  within 
modules  and  realization 
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Function 

Carrier  Frequency,  Bandwidth,  Dynamic  Range  ... 
Required  Resolution 


Function: 

Quality  (BER  ...  ) 
Quantity  (#  Channels) 
Time  Accuracy  (  Ts  ) 
Interfeces 


Size,  Weight  and  Power 
Parts  Count 
Analog  Parameters 


Figure  5  :  Radio  Functionality  Splitting 


Ground 

Ooeration 

Take  Off 

Enroute 

Combat 

Approach ! 

HF 

* 

VHF 

UHF 

JTIDS 

4,  W  W 

MLS/DMF-P 

Radar  Alt 

*  * 

GPS 

W  *  W 

*  * 

NIS 

*  * 

SATCOM 

_ _ 

_ *  *  * _ 

*  * 

=  no  use 
=  low  priority 
=  medium  priori! 
=  high  priority 


Figure  6  :  Functional  priorities  of  RF-use  during  flight  mission 
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RAPID  TARGETING  AND  REAL-TIME  RESPONSE: 

The  Critical  Links  for  Effective  Use  of  Combined  Intelligence  Products  in  Combat  Operations 

Danny  Searle 
Rick  Kirchner 
Ted  Fincher 
Frank  Armogida 

Naval  Air  Warfare  Center  Weapons  Division  (NAWCWPNS) 

China  Lake,  CA  93555-6100 
United  States 


SUMMARY 

A  variety  of  advanced  technology  projects  have 
demonstrated  the  key  components  required  to  provide  rapid 
targeting  for  a  real-time  response.  Forward  Hunter  (led  by 
NAWCWPNS)  and  Goldpan  (led  by  the  Air  Force's 
Aeronautical  Systems  Center)  are  examples  of  Real-Time 
Information  into  the  Cockpit/Offboard  Targeting 
(RTIC/OT)  demonstrations.  These  programs  have  shown 
the  value  of  providing  real-time  mission  updates  (based  on 
national  offboard  signals  and  imagery  intelligence)  to 
shooters  pursuing  time-critical  targets.  All  these  programs 
employed  national  exploitation  systems  and  source 
material  products  to  show  that  RTlC/OT  can  increase 
mission  effectiveness,  enhance  survivability,  and  increase 
operational  flexibility  against  time-critical  fixed  and 
mobile  targets.  Each  demonstration  has  focused  on 
different  aspects  of  critical  offboard  targeting 
technologies,  such  as  multisource  national/  theater 
intelligence  fusion,  rapid  targeting,  near-real-time  mission 
replanning,  data  dissemination,  and  onboard  processing. 
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OBJECTIVE 

While  the  goal  of  this  paper  is  to  present  an  historical 
perspective  of  RTIC/OT  technologies,  NAWCWPNS 
primary  focus  is  to  facilitate  the  transition  of  RTIC/OT 
technologies  and  converge  toward 

•  Establishing  a  near-term  RTIC/OT  concept  of 
operations  (CONORS)  based  on  existing  systems  and 
technologies  and  developing  a  migration  path  to  systems 
and  advanced  capabilities  slated  to  be  available  within  a 
2005  to  2010  time  frame. 

•  Refining  operational  prototypes  used  in  ongoing 
RTIC/OT  demonstrations. 

•  Preparing  near-term,  mid-term,  and  long-term 
technology  transition  and  deployment  plans  focused  on 
Navy  operations  and  joint  service  participation. 

PROBLEM 

What  are  the  warfighters'  needs?  Precision  attack  of  fixed 
and  rapidly  relocatable  targets  with  brief  attack  windows 
(e.g..  Scud  missile  launchers  in  Iraq,  camouflaged  tanks  and 
artillery  in  Bosnia,  and  antiship  surface-to-surface  cruise 
missile  (SSCM)  launchers  in  the  case  of  amphibious 
missions)  is  one  of  the  primary  areas  in  which  improved 
capabilities  are  needed.  National  and  theater  intelligence 
assets,  especially  imagery-capable  systems,  must  now 
detect  and  localize  the  target  and  threats  for  aircraft  in  a 
more  timely  manner  to  address  the  dynamic  battlefield 
(Fig  1). 

Current  tactical  strike  aircraft  weapon  inventories  and  rules 
of  engagement  dictate  that  the  weapon  platform  make  a 
direct  attack  and  acquire  the  target  with  a  high-resolution 
sensor  at  close  range.  For  the  aircraft  to  survive  in  a  hostile 
threat  environment,  minimal  exposure  time — "one  pass, 
one  kill" — and  situation  awareness  (i.e.,  where  are  the 
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nearby  threats?)  are  the  keys  to  survival.  Currently, 
accurate  target  coordinates  and  funnel  navigation  imagery 
(Fig  2)  meet  the  needs  of  man-in-the-loop  attacks  with  the 
present  weapon  inventory  (primarily,  laser-guided  bombs). 
Future  global  positioning  system  (GPS)  or  seeker-based 
bomb-on-coordinate  standoff  precision-guided  weapons 
(IOC  beyond  the  year  2000)  will  require  more  accurate 
target  coordinates  and  drive  advances  in  digital  data  links 
and  onboard  data  processing. 

Examination  of  the  Navy's  littoral  strike  mission  and  the 
Marine  Corps'  Operational  Maneuver  From  the  Sea  reveals 
that  the  carrier  and  amphibious  assault  ships  responsible 
for  providing  targeting  and  command/control  are  not 
outfitted  with  the  intelligence  feeds,  exploitation  systems, 
communications  links,  and  theater  battle  management 
(TBM)  capabilities  required  for  RTIC/OT.  The  same  is  true 
for  Air  Force  Close  Air  Support,  Deep  Strike,  and  Global 
Reach  capabilities. 

Furthermore,  Fleet  involvement  in  establishing  the 
operational  flow  from  sensor-to-shooter  (STS)  and  in 
developing  tactics  is  essential  to  field  an  operational 
RTIC/OT  capability.  Gaining  an  operational  understanding 


of  national  intelligence  capabilities  is  a  fundamental  skill 
required  to  produce  effective  products  in  time-critical 
combat  situations. 

OPERATIONAL  CONCEPT 

Fig  3  illustrates  our  advanced  RTIC/OT  operational  concept 
for  deployed  sea-based  applications.  Our  concept  is  focused 
on  the  capability  to  reduce  mission  planning  time,  as  well 
as  process  RTIC/OT  updates  during  the  mission  execution 
phase  in  response  to  dynamic  battlefield  conditions.  This 
concept  was  derived  from  our  baseline  architecture  used  to 
support  current  demonstrations  and  exercises,  and  is 
accomplished  by  using  common  electronic  digital  target 
folders  and  exploitation  tools  across  the  system.  Use  of  the 
following  key  elements  are  shown  in  Fig  4. 

•Multisource  Feeds.  Real-time  receipt  of  national 
signals  intelligence  (SIGINT)  data  (e.g.,  TRAP),  as  well  as 
the  capability  to  request  collection  of  or  access  to  existing 
archive  imagery  intelligence  databases  via  a  National  Input 
Segment  or  Custom  Product  network  (i.e.,  NIS,  CPNet 
reachback).  This  access  includes  the  capability  to  import 
theater-level  multisource  intelligence  data  (e.g.,  U-2, 
JSTARS,  RJ,  UAVs)  and  rapidly  fuse  with  national  products 


Time-Criticp!  Mobile  Targets 
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Fig  1 .  Time-Critical  Challenge. 


Fig  2.  Funnel  Navigation. 


to  improve  accuracy,  improve  situation  awareness,  and 
provide  the  backbone  for  rapid  targeting  and  RTIC  product 
generation. 

•Theater  Battle  Management.  Strike-  and  unit- 
level  planning  TBM  systems  to  generate  ATOs  and  preplan 
missions,  as  well  as  coordinate  and  avoid  conflicts  between 
aircraft  retasked  in  near- real-time  as  part  of  RTIC/OT 
operations.  Central  to  our  concept  is  a  RTIC  or  rapid¬ 
targeting  cell  connected  to  a  Carrier  Combat  Information 


Center  to  address  RTIC/OT-specific  operations,  including 
the  coordination  of  multisource  tasking,  intelligence  feeds, 
real-time  tasking  (RTT),  and  the  production  and 
dissemination  of  RTIC  materials. 

•Command  and  Control.  Shipboard  tracking  and 
communication  systems,  coupled  to  the  command  elements 
necessary  to  govern  the  overall  battlespace  and  ensure  that 
retasked  RTIC  sorties  operate  without  conflict  and  with 
adequate  priority  within  the  overall  strike  plan. 
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•Communications.  Composed  of  intelligence  and 
mission  planning  local-area  and  wide-area  networks,  as 
well  as  line-of-site  and  beyond-line-of-site  video  and 
digital  data  links  to  weapon  systems  to  support  the  data 
transfer  of  RTIC/OT  products. 

•Shooters.  Key  weapon  systems  and  onboard 
processing  equipment  to  receive  and  process  RTIC/OT 
products,  including  joint-service  strike  aircraft  (e.g., 
F/A-18,  F-15E),  associated  precision  guided  weapons  (e.g., 
JDAM),  long-range  standoff  weapon  systems  (e.g.,  JSOW, 
TLAM),  as  well  as  Marine-oriented  weapon  systems. 

TECHNOLOGY  BASE 

As  mentioned,  a  primary  emphasis  of  our  approach  is  to 
leverage  and  compliment  past  and  current  RTIC/OT- related 
projects  without  duplication  of  effort  and  make  maximum 
use  of  previously  developed  hardware  and  software  (Fig  5). 
Related  R&D  projects  conducting  core  technology 
development  include  the  following. 

•STS.  A  key  National  Technical  Means-sponsored  STS 
core  activity  to  provide  overall  RTIC  technology 
demonstration  support,  application  of  National  Technical 
Means,  and  prototype  multisource  intelligence  (MINT) 
exploitation  capabilities.  These  capabilities  include  rapid 
data  archive  retrieval,  national-tactical  imagery  and  SIGINT 
data  fusion,  targeting  materials  geopositioning,  and 
tactical  data  dissemination. 

•Arid  Hunter.  A  collaborative  NAWCWPNS  and 
NSAWC  project  to  enhance  the  effectiveness  of  naval 
strike  aircraft  against  rapidly  relocatable  targets.  A 
byproduct  of  Arid  Hunter  and  the  Air  Force's  RTF  program 
was  the  foundation  of  the  Mobile  Intelligence  Strike 
Support  Team  (MISST)  concept  that  provides  a  flexible, 
low-cost,  deployable  RTIC  cell  capability.  The  MISST 
concept  is  designed  to  support  distributed  personnel  and 
equipment  setup  at  designated  facilities  (i.e.,  AOC)  or  in  a 
stand-alone  capacity  via  collocation  and  integration  in  a 
commercial  deployable  van. 

•RTT.  An  Air  Force  Wright  Laboratory  (WL/AART)-led 
RTT  concept  development  program  to  evaluate  on/offboard 
concepts  for  adaptive  (offensive)  mission  management  to 
improve  air-to-ground  deep-strike  operations. 

•OBTEX.  An  Air  Force  Wright  Laboratory  (WL/AAZT)- 
led  series  of  offboard  targeting  experiments  (OBTEX)  to 


develop  and  demonstrate  the  feasibility  to  derive  target  area 
situation  information,  SAR-driven  precision  target 
coordinates,  SAR  seeker  templates;  and  program  a 
precision-guided  munition  in  near-real  time  from  offboard 
resources.  This  capability  includes  data  transfer  to  a  tactical 
strike  aircraft  via  line-of-site  and  satellite  communications 
using  Link- 16  protocols. 

•ATIMS.  The  NAVAIR-led  ATIMS  program  is 
leveraging  modular  processing,  advanced  display,  and 
virtual  reality  technology  to  demonstrate  a  capability  that 
provides  enhanced  awareness  of  engagement  parameters, 
alternative  mission  selection,  and  more  responsive  unit- 
level  mission  planning  and  rehearsal.  The  current  program 
is  focused  on  demonstrating  a  mission  management  device 
on  an  F/A-18  testbed. 

CAPABILITY  DEMONSTRATIONS 

A  key  tactical  demonstration  (Fig  6)  and  evaluation  that 
has  carried  the  burden  of  proof  for  RTIC/OT  effectiveness 
was  the  Navy-led  Arid  Hunter  series. 

•Arid  Hunter  Phases  I  &  11.  In  the  spring  of  1994, 
NAWCWPNS  China  Lake  and  the  Naval  Strike  and  Air 
Warfare  Center,  Fallon,  Nev.,  collaborated  on  Arid  Hunter, 
a  project  designed  to  enhance  the  effectiveness  of  naval 
strike  aircraft  against  rapidly  relocatable  targets.  The  staff 
at  Fallon  felt  that  the  effectiveness  would  be  increased  if 
the  latest  intelligence  information  were  available  to  the 
strike  group  throughout  the  entire  mission.  The  current 
practice  of  prebriefing  a  mission  provides  the  strike  group 
with  information  that  is,  at  best,  hours  old  by  the  time  the 
aircraft  enter  the  target  area.  More  than  100  Navy  and  Air 
Force  aircraft  participated  in  the  two  Arid  Hunter  exercises 
at  Fallon  from  March  through  May  of  1994  (Fig  7). 

The  purpose  of  Arid  Hunter  I  was  to  determine  if  in-cockpit 
imagery  would  be  useful  in  aiding  the  strike  process. 
Because  tactical  data  links,  such  as  Links-4,  -11,  and  -16, 
currently  can  transfer  little  more  than  tracking 
information,  China  Lake  provided  an  image-processing 
ground  station  and  transmitter  (dubbed  the  Rapid  Imagery 
Transmission  to  Aircraft  (RITA)  system),  which  was 
compatible  with  the  Navy's  AN/AWW-9  and  -13  weapon¬ 
wide  data-link  pods  and  the  Air  Force's  AN/AXQ-14  system. 
RF-4  and  F-14  Tactical  Air  Reconnaissance  Pod  Systems 
(TARPS)  imagery  was  analyzed  in  a  simulated  CVIC  and 
transmitted  to  aircraft  carrying  data-link  pods.  A  control 
group  of  similar  aircraft  attempted  to  find  the  target  using  a 


Fig  5.  Technology  Base. 
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Fig  6.  Capability  Demonstrations. 
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Fig  7.  Arid  Hunter  Data  Flow. 


standard  preflight  brief  supplemented  by  accurate  GPS 
coordinates  (300  feet). 

In  Arid  Hunter  I — against  a  camouflaged  Scud  transporter/ 
erector/launcher  (TEL)  array  with  nine  support  vehicles  and 
a  decoy — 85%  of  the  aircraft  without  imagery  were  unable 
to  find  the  target,  and  only  15%  found  anything  else  in  the 
array  (usually  the  decoy).  No  one  in  this  group  found  the 
actual  TEL.  With  imagery,  the  results  were  dramatically 
better;  73%  found  the  TEL  and  another  18%  found  another 
vehicle  in  the  array.  Only  9%  failed  to  find  any  target 


(Fig  8).  Target-acquisition  time,  although  not  measured  as 
part  of  the  test,  was  significantly  less  for  the  group  with 
imagery. 

Arid  Hunter  II  took  a  closer  look  at  the  effect  of  imagery  on 
target-acquisition  time.  A  scenario  was  used  in  which  the 
Scud  TEL — uncamouflaged  and  with  no  support  vehicles  or 
decoy — moved  daily  among  16  locations  within  an  800- 
square-mile  killbox.  Participating  aircraft  were  divided  into 
three  groups:  (1)  killbox  coordinates  only,  (2)  GPS 
coordinates  of  the  target,  and  (3)  GPS  coordinates  and 
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COORDINATES  + 
IMAGERY 

COORDINATES 

ALONE 

KILLBOX 


0 


5 


10 


15 


AVG  TIME  IN  THREAT  ENVELOPE,  MINUTES 


Fig  9.  Target-Acquistion  Time. 


imagery  via  the  data-link  pods.  In  poor  weather  the  average 
time  to  find  the  target  was  approximately  14  minutes  for 
those  aircraft  searching  the  killbox,  more  than  9  minutes 
for  those  with  GPS  coordinates,  and  just  over  5  minutes  for 
those  with  GPS  coordinates  with  imagery  (Fig  9). 

Arid  Hunter  was  similar  in  design  and  results  to  Air  Force 
Project  Goldpan  '93.  From  this  exercise,  the  Air  Force 
developed  a  Mission  Need  Statement  (MNS)  for  RTIC.  The 
Naval  Strike  Warfare  Center  modified  this  MNS  slightly 
and  submitted  it  for  approval.  The  synergism  between  the 
Air  Force  and  Navy  RTIC  technology  communities  led  the 
Air  Force  to  choose  the  NAWCWPNS  ground  station  as  the 
exploitation  and  transmit  elements  for  Goldpan  '95-1  at 
Roving  Sands  and  Goldpan  '95-11  (High  Gear). 

Examples  of  other  related  proof-of-concept  demonstrations 
that  have  incorporated  the  RTIC/OT  technologies  include 
the  following. 

•Roving  Sands  '95.  A  Joint  Chiefs  of  Staff- 
sponsored  exercise  held  in  May  1995  at  White  Sands 
Missile  Range,  N.  Mex.  This  demonstration  included 
MISST  ground  station  connected  to  national  archive  and 
real-time  ASARS  and  SIGINT  collection  systems,  as  well  as 
local  Command  and  Reporting  Centers  (CRCs)  to  support 
generation  of  RTIC  products.  F/A-18  and  F-15E  strike 
aircraft  simulated  prosecution  of  time-critical  TBMs  (i.e.. 
Scuds).  This  demonstration  also  included  generation  of 
offboard  mission  replanning  products  (e.g.,  new  route  and 
weapon-launch  data)  sent  to  the  ATIMS  flight  simulation 
laboratory  using  Link- 16  protocols  over  a  long-haul  DBS 
link. 


•Deeplook.  A  collaborative  Utah  Air  National  Guard 
and  NAVAIR  ATIMS-sponsored  exercise  held  in  June  1995 
at  Dugway  Proving  Grounds,  Utah.  This  demonstration 
included  Navy-developed  Tactical  Aircraft  Mission 
Planning  System  (TAMPS)  ground  station  equipment  tied 
to  an  Apache  helicopter  equipped  with  tactical  data  links 
and  real-time  situation  display.  As  part  of  Deeplook  '96, 
this  effort  is  being  expanded  to  include  multiple  Apache 
and  ground  armor  vehicles,  satellite  communications,  and 
MISST-based  offboard  precision  targeting  equipment. 

•Project  Strike  Phase  I.  An  Air  Force  ACC/DR  and 
TENCAP  (SWC/DOZ)-led  demonstration  conducted  in 
August  1995  involving  B-IB  and  F-15E  strike  aircraft  in 
deep-strike  precision-attack  mission  scenarios  at  the  Utah 
Test  and  Training  Range.  Testbed  assets  were  equipped  with 
onboard  threat  situation  displays  and  image  processing 
equipment  to  receive  offboard  imagery-derived  RTIC 
products  sent  via  JTIDS  and  UHF  SATCOM  digital  data 
links.  The  RTIC  products  were  generated  by  MISST-based 
targeting  and  mission  planning  systems  hosted  within  a 
simulated  AOC  at  the  Hurlburt  AFB  Battle  Staff  Training 
School. 

•OTL  #166.  A  Navy-sponsored  demonstration 
performed  in  conjunction  with  the  1995  Tomahawk 
Operational  Test  Launch  #166  and  JWID  '95  to  evaluate 
enhanced  collaborative  planning  and  rapid-targeting 
technologies.  During  this  exercise,  the  MISST  ground 
station  supported  pursuit  of  time-critical  fixed  targets  in 
simulated  engagements  at  Fallon  NAS,  including  transfer  of 
Pioneeer  UAV  targeting  information  to  the  cockpit  to 
augment  national  imagery-based  targeting. 
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•TMD-HG  (Goldpan  '95-11).  An  Air  Force  ESC/ZJ- 
led  theater  missile  defense  High  Gear  demonstration 
conducted  in  November  1995  at  White  Sands  Missile 
Range.  High  Gear  examined  the  timeline  and  accuracy 
requirements  necessary  to  prosecute  TBM  launchers.  This 
test  involved  F-15E  aircraft  equipped  with  GBU-15  video 
and  JTIDS  communications  cued  from  a  ruggedized  MISST 
ground  station.  The  ground  station  was  tightly  integrated 
with  airborne  launch  detection  and  ASARS  surveillance 
sensor  platforms  to  provide  RTT  cueing  and  theater 
imagery,  resulting  in  extremely  short  time  lines  from 
launch  detection  to  target  destruction. 

•Project  Goldstrike.  EUCOM  requested  deployment 
of  the  ruggedized  MISST  ground  station  and  other  Goldpan 
elements  to  support  potential  strike  operations  in  the 
Bosnian  theater.  The  sysem  supports  F/A-18,  F-15E,  and 
A-6  strike  aircraft  with  RTIC  products  derived  from  ASARS, 
UAV,  and  national  imagery.  The  5th  Allied  Tactical  Air 
Force  (ATAF)  plans  include  moving  the  transmitter  for 
better  coverage  and  the  addition  of  RTIC  capabilities  for 
the  F-16. 

RTIC/OT  NEAR-TERM  GOALS 

It  is  critical  at  this  time  to  build  upon  the  successes  of  the 
past  2  years  to  establish  a  near-term  operational 
capability,  develop  CONOPS,  and  establish  figures  of  merit 
in  the  areas  of 

•Mission  effectiveness  Responsiveness,  accuracy, 
lethality,  collateral  damage 

•Enhanced  survivability  Situation  awareness,  threat 
avoidance 

•Operational  flexibility  Retargeting,  reallocation, 
rules  of  engagement,  tactics 

•Operational  suitability  Operator  workload,  resources 
loading,  weather  restrictions 

The  lack  of  these  items  is  a  major  stumbling  block  to 
transition  (Fig  10).  As  a  means  of  addressing  these  issues, 
we  began  the  development  of  an  STS  infrastructure  that, 
with  synergistic  programs,  will  evolve  into  a  production 
capability  at  NAWCWPNS  to  provide  custom  intelligence 
products  in  direct  support  of  operational  forces. 


The  key  pieces  being  put  in  place  in  FY96  are  several 
wideband  secure  communications  links  to  key  intelligence 
agencies;  500-gigabyte  imagery  servers  and  exploitation 
systems  at  China  Lake  and  Point  Mugu  sites;  and  high- 
bandwidth  communications  to  a  customized  rapid-targeting 
cell  at  the  Naval  Surface  Warfare  Center,  Fallon.  This 
optimized  cell  will  be  made  available  to  the  joint  services 
for  end-to-end  integration  and  testing  of  offboard  targeting 
prototypes. 

Over  the  next  few  years,  we  plan  to  provide  direct  Global 
Broadcasting  System  (GBS)  uplink  capability  for 
connectivity  to  attack  aircraft  carriers  (CVAs)  and 
amphibious  assault  ships  (LHAs),  while  we  work  out  the 
operational  and  architectural  issues  using  the  RTIC  cell  at 
Fallon.  This  aggressive  buildup  is  targeted  at  our  primary 
objective  of  facilitating  the  transition  of  RTIC/OT 
technologies,  as  well  as  satisfying  our  near-term  goals  of 
developing  CONOPS  and  figures  of  merit.  The  cell  at  Fallon 
will  be  used  to  evaluate  the  CONOPS  against  the  figures  of 
merit  and  produce  accepted  guidance  for  Fleet  units 
(Fig  11). 

The  full  capabilities  of  the  RTIC/OT  concept,  as  spelled  out 
in  the  Navy  and  Air  Force  MNSs,  cannot  be  achieved  by 
any  currently  developed  system.  The  final  configuration 
will  be  a  "system  of  systems,"  encompassing  national  and 
theater  intelligence  systems,  a  variety  of  exploitation 
systems,  and  several  communication  links  (Fig  11).  For 
strike  aircraft,  the  most  limiting  factor  has  been  in  the 
RTIC  data  link.  Current  data  links  used  for  command  and 
control  are  not  available  in  sufficient  quantities  and  have 
insufficient  bandwidth  to  transmit  RTIC  data  in  a 
reasonable  amount  of  time.  These  wideband  digital  non- 
line-of-sight  capabilities  will  not  be  realized  until 
advanced  communications  systems  are  available  in  large 
quantities  during  the  2004  to  2010  time  frame.  The  addition 
of  new  or  modified  data-link  transceivers  to  the  F/A-18  or 
other  current  tactical  aircraft  is  clearly  cost-prohibitive  for 
demonstration  or  gap-filler  purposes. 

However,  an  interim  solution  is  to  use  transmitters 
compatible  with  existing  weapon  data-link  terminals, 
such  as  the  AN/AWW-9,  AN/AWW-13,  and  AN/AXQ-14. 


Fig  10.  Transition  Gap. 
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Fig  11 .  RTIC  Cell  Operations. 


These  terminals  provide  a  quick,  simple,  wide-bandwidth  tactics.  Considerable  attention  needs  to  be  focused  in  these 

pipeline  to  the  aircraft  with  Navy/Air  Force  areas  if  this  technology  is  to  transition  in  the  near  future, 

interoperability,  and  leverage  the  200-million-dollar 

investment  made  in  these  systems  over  the  past  20  years.  Development  and  deployment  of  a  near-term  RTIC/OT 
The  Navy  and  Air  Force  have  about  350  data-link  pods  for  system  now  will  provide  a  considerable  experience  base  for 
the  A-6,  F/A-18,  and  F-15E.  integration  with  more  advanced  systems,  such  as 

JTIDS/Link-16,  when  they  become  widely  available.  Navy 
CONCLUSION  and  Air  Force  users  consistently  request  a  relay  and  storage 

Evolving  RTIC/OT  technology  offers  great  promise  in  capability,  and  these  extensions  would  greatly  enhance  the 

terms  of  survivability,  lethality,  and  rapid  response.  Time  value  of  the  current  system  by  easing  some  of  the  geometry 

and  again,  the  Navy  and  Air  Force,  along  with  several  other  constraints  associated  with  using  the  podded  receivers  and 
agencies,  have  demonstrated  the  value  of  RTIC/OT  and  the  provide  a  future  system  development  surrogate, 

technical  feasibility  of  several  different  approaches.  The  Considerable  investments  have  been  made  to  bring 

lack  of  integration  and  coordination  across  all  the  system  RTIC/OT  to  the  strike  community.  This  transition  is  not 

elements  is  a  serious  issue,  as  is  the  lack  of  CONORS  and  complete,  but  we  can  see  the  light  at  the  end  of  the  tunnel. 
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1.  SUMMARY 

A  review  of  the  modular  avionics  concepts  is 
presented  in  light  of  DOD’s  mandate  to  change 
the  military’s  acquisition  process  and  the  i^ecent 
deUvery  of  advanced  modular  processing 
systems  developed  to  meet  the  demands  of  the 
next  generation  avionics.  Future  trends -in 
avionics  are  discussed  along  with  how  this  will 
impact  the  modular  standards  just  now  being 
implemented. 

Modular  avionics  is  the  most  dominant  feature 
of  our  advanced  avionics  systems.  Initially 
mandated  because  of  the  projected  cost 
advantages,  modular  avionics  also  provides 
significant  performance  potential.  Modular 
avionics  is  characterized  by  configurations  that 
partition  the  system  into  building  blocks  diat 
feature  integration,  modularity,  and 
commonality.  The  main  focus  of  these  concepts 
is  initially  being  applied  to  the  digital  core 
avionics  for  which  the  F-22  Common  Integrated 
Processor  is  a  powerful  and  innovative 
realization.  The  USAF  PAVE  PACE  and 
MASA  programs  extended  the  current  concepts 
further  and  the  initiatives  to  integrate 
commercial-off-the-shelf  (COTS)  technology 
has  fostered  innovative  solutions  to  improve 
increased  availability  at  reduced  costs. 
Functions  within  the  aircraft  will  become  more 
integrated  requiring  innovative  approaches  to  the 
management  of  the  computer  resources  and 
distribution  of  information. 


2.  INTRODUCTION 

Modular  integrated  avionics  (AVIation 
ElectrONICS)  is  the  single  most  significant 
change  in  advanced  avionics  systems.  Initially 
mandated  because  of  the  projected  cost 
advantages,  modular  integrated  avionics  also 


provide  significant  performance  potential.  With 
the  advent  of  Pave  Pillar,  avionics  architecture 
has  taken  a  broader  and  more  important  role  in 
avionics  acquisition  plans.  The  more  recent 
initiatives,  to  use  already  developed  components 
and  especially  components  from  the  commercial 
sector,  have  further  broadened  this  role. 
Architecture  is  the  framework  by  which  the  sub¬ 
systems,  functions  and  components  and  their 
operation  are  defined.  Previously  specified 
within  a  program  only  after  mission  analysis  and 
functional  definition,  the  Services  are 
undertaking  a  new  acquisition  strategy  by 
defining  an  avionics  architecture  as  a  generic 
solution.  Modular  architectures  refer  to 
architectures  such  as  Pave  Pillar  which  feature 
modularity  through  specification  of  standard 
modules  or  building  blocks.  Avionics  includes 
most  electronic  equipment  installed  on  an  air 
vehicle  including  the  vehicle  management 
systems  and  the  stores  management  system. 

3.  ARCHITECTURE 

The  architecture  may  be  looked  upon  as  being 
constructed  of  several  layers  of  definition.  A 
special  and  significant  layer  is  that  of 
partitioning.  Partitioning  is  the  attribute  that 
gives  rise  to  three  key  features:  integration, 
modularity,  and  commonality.  These  three 
features  are  independent  of  each  other  and  their 
degree  of  use  may  vary  greatly  across 
applications.  It  should  be  noted  that  this  layer  of 
partitioning  applies  to  software  as  well  as 
hardware.  These  three  features  also  impact  the 
efficiency  of  tlie  architecture  in  the  utilization  of 
the  system  resources.  Integration  is  defined  as 
the  sharing  of  common  tasks  or  items  to  gain 
system  fault  tolerance  and  flexibility. 
Modularity  is  the  partitioning  of  a  system  into 
reconfigurable  and  maintainable  items. 
Commonality  is  partitioning  to  maximize  the  use 
of  identical  configuration  items  across  the  range 
of  functions  and  applications. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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Broad  use  of  modularity  and  commonality 
require  the  application  of  standards  to  define 
significant  interface  and  operating  characteristics 
of  various  modules  or  other  elements.  When 
these  standards  become  accepted  by  a  broad 
segment  of  industry  and  are  maintained  in  an 
industry  wide  forum,  they  become  “open” 
standards.  This  enables  various  companies  to 
provide  elements  from  various  applications  and 
to  significantly  reduce  development  effort 
required  for  a  particular  application.  Thus,  non- 
developmental  items  (NDI)  and  COTS  items  can 
be  apphed  to  sophisticated  military  applications 
in  ways  not  previously  attainable.  Advances  in 
the  ruggedness  and  leliabihty  of  commercially 
available  electronics  from  aviation  and 
automotive  mai'kets  have  been  significant, 
further  enabling  these  applications. 

3.1  Integration 


more  complex  operations  has  been  an  ongoing 
process.  Over  the  past  forty  to  fifty  years, 
subsystems  formerly  requiring  multiple  units 
were  reduced  to  a  single  Line  Replaceable  Unit 
(LRU)  while  performing  more  complex  tasks. 
With  new  advances,  multiple  subsystems  can  be 
housed  in  a  single  unit. 

Figure  1  provides  a  stylized  depiction  of  the 
avionics  architecture  transition  currently 
underway. 

Most  currently  fielded  architectures,  e.g.,  F-16 
and  F-15,  are  “Federated”  systems.  In  these 
systems,  discrete  subsystems  are  interconnected 
by  the  1  Mbps  standard  avionics  multiplex  bus 
(MlL-STD-1553).  The  transition  to  an 
integrated  architecture  involves  grouping  like 
functions  together,  i.e.,  signal/data  processing, 
rather  than  including  these  functions  in  separate 
subsystems. 


As  electronic  components  have  achieved  higher  ,  „  .  .  ,  ,  u  xtaa^atti 

and  higher  densities,  the  integration  of  more  and  The  following  quote  is  taken  from  the  NAVAIR 
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Figure  1.  Modern  Avionics  Architecture.  Evolution  from  current  avionics  features  increasing 
modularity  and  resource  sharing  of  common  modules  through  integration. 
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Study  entitled  “Advanced  Avionics  Ai'cliitec- 
ture.”  (1)  “Increased  processing  power  and 
very  high  levels  of  circuit  integration  at  the 
microcircuit  level  have  allowed  the  capability  of 
some  earlier  subsystems  to  be  concentrated  into 
a  single  module.  Integrated  avionics 
architectures  follow  the  research  approaches 
pioneered  in  the  Air  Force  Pave  Pillar  program 
and  in  Navy  avionics  and  modular  packaging 
research  of  the  last  twenty  years.  Architectural 
standardization  under  the  Tri-Service  Joint 
Integrated  Avionics  Working  Group  (JIAWG) 
promotes  the  use  of  integrated  avionics 
architectures  packaged  in  standard  modules  of  a 
SEM-E  form  factor  and  installed  in  several 
avionics  integrated  racks  or  module  cabinets. 
This  approach  was  originally  focused  on  cost 
savings  through  the  use  of  a  family  of 
“common”  modules  that  would  be  applicable  to 
a  wide  cross  section  of  avionics  applications. 
The  Air  Force  F-22  fighter  and  the  AiTny  RAH- 
66  Aircraft  are  developmental  aircraft  that 
employ  the  JIAWG  integrated  architecture, 
“common”  module  approach  to  avionics.” 

The  approach  has  been  selected  as  the  initial 
baseline  for  the  Joint  Advanced  Strike 
Technology  (JAST)  program  as  well  (2). 

A  key  driver  towards  increased  integration  has 
been  the  significant  increase  in  affordability 
which  results  from  the  significant  increase  in 
reliability.  As  the  number  of  individual 
components  has  decreased  and  the  reliability  of 
each  component  has  increased,  the  reliability  of 
the  system  has  increased  significantly.  Module 
reliability  in  excess  of  10,000  hours.  Mean  Time 
Between  Failures,  is  common.  With  this  level  of 
reliability,  two  level  maintenance  is  practical, 
resulting  in  an  additional  dimension  of  savings. 

3.2  Modularity 

Another  independent  partitioning  feature  is 
modularity.  Modularity  provides  the  capability 
to  reconfigure  to  satisfy  a  broad  range  of 
applications.  Several  approaches  are  available 
ranging  from  standardizing  at  the  chip  level  to 
the  subsystem  level  or  line  replaceable  unit 
(LRU).  The  mechanical  interface  specification, 
known  as  Air  Transportable  Rack  (ATR),  was 
developed  originally  by  ARINC,  the  commercial 
airlines  standards  organization,  and  has  achieved 
wide  use  in  both  commercial  and  military 
aircraft.  The  most  popular  sizes  range  from  1/2 
ATR  to  full  ATR. 


More  recently,  due  to  the  chip  densities 
achievable,  complete  functions  are  able  to  be 
contained  in  a  single  module.  This  module 
definition  was  adopted  by  JIAWG  as  previously 
noted. 

3.3  Commonality 

The  other  feature  of  partitioning  is  commonality. 
Commonality,  when  enabled  by  modularity, 
provides  the  most  significant  factor  in  reducing 
costs  for  the  avionics  system  by  reducing  the 
number  of  unique  module  types.  A  possible 
disadvantage  of  commonality  is  that  more 
modules  may  be  required  in  the  system  due  to 
the  inefficiencies  resulting  from  applying  these 
common  modules  to  functions  -  perhaps  more 
efficiently  performed  by  special  modules.  A 
trade-off  is  neeessitated  between  module  types 
and  number  of  modules  in  a  system.  Integration 
without  common  modules  offers  few  benefits 
since  the  sharing  of  resources  across  functions 
requires  those  resources  to  be  common,  and 
fault  tolerance  via  module  sparing  becomes 
impractical. 

3.4  Open  Systems 

The  following  definition  of  an  “Open  System”  is 
from  the  letter  by  Dr.  Paul  Kaminski  (3),  Under 
Secretary  of  Defense  for  Acquisition  and 
Technology:  “Open  System  Specifications  and 
standards  are  consensus-based  public  or  non¬ 
proprietary  specifications  and  standards  for 
systems  and  interfaces  of  hardware,  software, 
tools  and  architecture.” 

According  to  Dr.  Kaminski,  these  open 
standards  are  to  be  used  “To  the  greatest  extent 
practical  in  the  acquisition  of  weapon  systems 
electronics.” 

There  are  several  organizations  cuiTently 
regarded  as  responsible  agencies  for  the 
development  and  maintenance  of  various 
standards.  Some  examples  are:  the  Society  of 
Automotive  Engineers,  Institute  of  Electrical  and 
Electronic  Engineers,  Aeronautical  Radio,  Inc., 
and  VME  International  Trade  Association. 

Thus,  a  working  definition  of  an  “Open  System” 
is  one  in  which  the  specifications  are  developed 
by  consensus  in  a  public  or  industry  forum  and 
published  and  maintained  by  some  recognized 
group.  As  stated  in  Dr.  Kaminski’s  definition,  a 
broad  range  of  topics  are  covered  by  these 
specifications.  Systems  architecture,  hardware, 
and  software  are  specifically  included. 
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3.5  Commercial-Off- The-Shelf 

In  conjunction  with  open  systems,  the 
government  is  attempting  to  reduce  the  cost  of 
the  avionics  acquired  by  procuring  commercially 
available  equipment  in  areas  where  special  built 
equipment  has  been  acquired  in  the  past.  Some 
of  the  potential  problems  to  be  addressed  in  the 
acquisition  of  COTS  equipment  are  discussed  by 
Trujillo  (4).  As  with  open  systems,  the 
requirement  for  the  acquisition  of  COTS-based 
equipment  can  be  applied  over  a  broad 
spectrum.  COTS  can  be  applied  at  the 
subsystem,  box,  module,  or  piece  part  level. 
And  it  can  be  applied  to  software  as  well. 

Reference  1  defines  four  criteria  that  must  be 
met  when  considering  whether  to  apply  COTS 
for  military  avionics  systems.  These  are: 

•  Reliable  operation  under  severe 
environmental  requirements. 

•  Flight  Critical/Sumvability  designs 
requiring  “Real  Time”  system  response. 

•  Need  for  a  multi-level  Infomiation  Security 
(InfoSec)  System  which  applies  throughout 
the  avionics  suite. 

•  Systems  must  be  compatible  with  military 
support  systems. 

4.  BACKGROUND 

Because  of  the  important  role  played  by  real¬ 
time  processors  in  sensor  systems,  their 
development  and  application  have  been  led  by 
the  avionics  manufacturers  and  are  a  major 
product  line  specialty.  As  an  example  of  this,  a 
review  of  tliis  development  and  application  by 
Hughes  Aircraft  Company  will  provide  insight 
into  processor  developments  for  real-time 
applications.  Since  1949,  Hughes  has 
successfully  developed,  produced,  and 
supported  sensor  systems  of  wide  variety  and 
progressively  advanced  capability  of  avionics, 
ground-based,  shipboard,  and  space  usage. 
Hughes  has  pioneered  many  advanced  processor 
technologies  including  the  first  airborne  digital 
computer,  real-time  digital  synthetic  amay  radar 
processor,  operational  airborne  fast  Fourier 
transfonn  (FFT)  signal  processor, 
programmable  airborne  FFT  signal  processor, 
and  the  common  integrated  processor. 

Recently,  processor  systems  have  been 
produced  for  the  F- 14,  F-15,  F/A-18,  TR-1,  B- 


2,  C-17  avionics  and  other  major  systems.  This 
broad  experience  in  processor  technology  and  an 
in-depth  understanding  of  the  applications  and 
system  architecture  were  key  elements  in  being 
selected  by  the  Lockheed  F-22  Advanced 
Tactical  Fighter  team  to  develop  the  Common 
Integrated  Processor  (CIP)  for  the  sensor  and 
mission  processing.  Following  a  successful 
DemonstrationA/'alidation  phase  and  an 
Engineering/Manufacturing  Development  Phase, 
the  first  production  processor  for  the  F-22  was 
delivered  in  August  of  1995. 

5.  PROCESSOR  DESCRIPTION 

Within  the  avionics  architecture,  the  Hughes 
Modular  Processor  (HMP)  line  supports  all 
signal  processing,  data  processing,  digital 
input/output  (I/O),  and  data  storage  functions 
using  a  single,  integrated  hardware  and  software 
design.  Using  fully  integrated  signal  and  data 
processing,  the  HMP,  as  in  the  F-22  CIP,  is 
distinguished  from  federated  or  partially 
integrated  architectures  because  it  provides  the 
requisite  high  perfoiTnance  computing  power 
with  lower  installed  weight,  volume,  power, 
and  cost.  This  integrated  architecture 
incoiporates  the  PAVE  PILLAR  concepts  and 
implements  Joint  Integrated  Avionics  Working 
Group  (JIAWG)  standards.  These  include  the 
Pl-bus  and  TM-bus  and  the  Dual  Data 
Processing  Element  (DDPE)  which  employs  a 
high  performance  32-bit  Central  Processing  Unit 
(CPU),  the  Intel  i960™  Reduced  Instruction  Set 
Computer  (RISC)  processor.  The  i960 
extended  instruction  set  architecture  (ISA)  is  one 
of  two  32-bit  instmction  set  architectures 
recognized  by  the  JIAWG  as  the  basis  for 
standardization  of  32-bit  embedded  avionics 
computers.  The  PI  bus  standard  is  now  “open” 
in  the  commercial  sector  and  is  defined  by  SAE 
Standard  4710. 

5.1  Overview 

An  overview  of  the  Hughes  Modular  Processor 
product  line  is  shown  in  Figure  2.  It  ranges 
from  a  large,  integrated  avionics  processor,  seen 
in  Figure  2a,  to  smaller  integrated  signal/data 
processing  machines  and  even  less  complex  data 
processors,  seen  in  Figure  2d.  In  large-scale 
avionics  processing  applications,  the  total 
available  signal  and  data  processing  performance 
is  massive:  over  350  MIPS  general  purpose 
processing  and  9  BOPS  of  parallel 
programmable  signal  processing  throughput. 
This  perfoiTnance  is  indicative  of  the 
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performance  for  the  HMP  Common  Integrated 
Processor  configuration. 

5.2  Architecture  Family 

The  avionics  processing  configuration  provides 
sensor  processing  functions  for  Integrated 
Communications  Navigation  Identification 
(ICNIA),  Integrated  Electronic  Warfare 
(INEWS),  fire  control  radar  and  supports 
infrared  search  and  track.  AH  mission  avionics 
functions,  including  display  processing,  are  also 
included.  This  diversity  of  application  is 
supported  by  an  extensive  set  of  low-latency 
red-time  operating  system  services  and  easy  to 
use  software  tools  -  all  developed  in  Ada.  The 
support  software  tools  are  hosted  on  Digital 
Equipment  Corporation  VAX  computers. 

The  HMP  architecture  is  ‘open.’  Along  with  a 
Hughes-supplied  Signal  Processing  Element 
(SPE),  three  other  specialized  signal  processing 
elements  developed  by  other  suppliers  have  been 
successfully  integrated,  as  well  as  fiber  optic 
transmitter/receiver,  avionics  bus  interface  (ABI) 
input/output,  and  Standard  Electronic  Module-E 
(SEM-E)  modular  voltage  regulator  modules. 
The  open  architecture  was  achieved  by 
developing  detailed  hardware  and  software 
interface  documentation  of  the  HMP 
architecture,  hosting  working  group  meetings 
with  module  suppliers,  and  holding  detailed 
design  reviews  of  the  processor  and  vendor- 
supplied  modules.  VHDL  modeling  and 
standard  interface  components  will  further 
enhance  the  ease  of  open  architecture  realization. 


To  date,  over  600,000  lines  of  Ada  application 
code  has  been  developed  and  integrated  on  these 
HMP  machines  by  seven  other  companies  and 


Figure  2.  Modular  Processor  Architecture 
Enables  Expansion  to  Fit  the  Application. 


by  Hughes.  This  high  intensity,  multi-user, 
multi-application  user  base  has  resulted  in  rapid 
maturation  of  the  support  software  tool  set.  In 
addition  to  application  software,  the  Hughes 
developed  plus  vendor-supplied  support 
software  exceeds  800,000  lines  of  code. 

High  Performance  SEM-E  form  factor 
processing  modules  were  developed  and 
demonstrated  as  part  of  the  ATE  program 
DemonstrationA^alidation  phase  in  1990.  The 
Dual  Data  Processing  Element  (DDPE),  using 
the  Intel  i960  RISC  CPU,  implements  the 
special  memory  access  control  provisions  of  the 
CPU’s  extended  architecture,  supporting  a 
trusted  computing  environment.  The  DDPE 
provides  30  MIPS  throughput  and  4  Mbytes  of 
SRAM  memory  implemented. 

The  SPE,  demonstrated  in  1995  in  SEM-E  form 
factor,  is  programmable  pipeline  architecture 
aiTay  processor  with  450  MOPS  fixed  point  and 
125  MOPS  floating  point  performance.  The 
SPE  is  macro  programmable  and  features  an 
extensive  instruction  set,  directed  at  radar  and 
electro-optical  signal  processing  perfomiance.  It 
provides  a  12;1  improvement  in  throughput  per 
unit  of  area,  weight,  and  power  compared  with 
the  previous  generation  F-15E  SPEs.  Arrays  of 
SPE  may  be  used  for  high  throughput 
applications  and  the  cluster  architecture  supports 
the  low  overhead  control  of  multiple,  parallel 
processors  operating  on  shared  data. 

5.3  Modular  Approach 

The  integrated  signal  and  data  processing  of  the 
HMP,  coupled  with  the  efficient  cluster 
architecture,  minimizes  the  required  interface 
modules  and  processing/memory  elements,  as 
well  as  physical  interfaces.  In  addition,  high 
density  packaging  technologies  were  developed 
peimitting  entire  functions  to  be  fabricated  on  a 
single  SEM-E  module.  For  instance,  the  DDPE 
SEM-E  module  includes  the  Intel  i960MX  RISC 
processor,  two  dual  telemetry  (TM)  bus 
interfaces,  a  Pl-bus  interface,  stait-up  ROM, 
fault  log,  and  4  Mbytes  of  high  bandwidth 
SRAM  memory.  Figure  3  shows  the  DDPE 
module. 

As  developed  for  the  F-22,  the  HMP  products 
use  a  liquid  cooling  concept.  The  cooling  liquid 
flows  through  a  seipentine  path  in  the  center  of 
the  two  sided  module.  Tliis  technique  achieves 
high  cooling  efficiency  enabling  high  power 
dissipation.  For  retrofit  applications  where 
liquid  cooling  is  not  available,  different  form 
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factors  have  been  successfully  used.  For 
example,  an  upgrade  to  the  AN/APG-73  radar 
used  in  the  Navy  F/A-18,  uses  a  Standard 
Avionics  Module  (SAM)  design  approach 
utilizing  air  flow  through  in  the  module  core. 
Conduction  cooled  examples  have  been 
developed,  as  well. 

5.4  Support  Software 

One  of  the  most  significant  advantages  of 
modular  common  integrated  processing  is  the 
support  software  user  base  is  maximized  and 
focused  on  the  use  of  a  single  set  of  tools.  As  a 
processor  developer,  Hughes  has  used  the  HMP 
tools  to  develop,  debug,  and  test  hundreds  of 
thousands  of  lines  of  signal  and  data  processing 
software.  However,  on  the  ATF  DemA^al 
program  alone,  the  Lockheed,  Boeing,  General 
Dynamics  team  developed  over  5CK),0(K)  lines  of 
Ada  and  150,000  lines  of  signal  processor  code. 
This  has  accelerated  the  maturity  of  the  HMP 
tool  set  -  and  has  resulted  in  significant 
optimizations  for  a  broad  spectrum  of  users. 

The  HMP  software  development  products 
comprise  a  complete  Software  Engineering 
Environment.  Three  of  them  are  of  special  note: 
the  Ada  Compiler,  User  Console  Interface  and 
Debug,  and  the  Ada  Operating  System. 

Hughes  has  funded  Irvine  Compiler  Corporation 
(ICC)  to  develop  the  Ada  compiler.  ICC  was 
put  under  contract  in  1987,  participated  in  the 
ATF  Dem/Val  program,  and  is  the  compiler 
source  for  the  ALR-67  Advanced  Special 
Receiver  program.  ICC  developed  their  Run 
Time  Systems  to  a  common  interface  design 
optimized  for  the  Hughes  Core  Operating 
System  (OS).  ICC  markets  their  i96()  32-bit 
compilers  directly  or  they  can  be  purchased 
through  Hughes  as  a  package  with  other  HMP 
support  software  products. 

The  HMP  user  console  software  provides  debug 
access  to  HMP  computing  elements,  a  real  time 
symbolic  debugger,  and  the  low  level  instmction 
tracing  access  unique  to  the  i960MX.  Multi¬ 
user  capability  enables  multiple  concuirent 
debug  sessions  to  be  run  with  independent  Ada 
applications  executing  on  the  host  HMP. 

The  Hughes  Core  OS  is  the  first  32-bit  real  time 
multi-program,  multi-tasking  operating  system 
written  in  Ada.  Now  in  its  fourth  generation  of 
development,  the  Core  OS  uses  a  preemptive, 
priority-driven  Ada  tasking  model  with  task 
priority  arbitration  across  program  boundaries. 


It  provides  Ada  program  support,  semaphores, 
I/O  support,  and  hardware/software  debug 
support.  In  addition,  it  supports  the  HMP 
software  architecture  which  is  based  on  directed 
graphs  that  allow  computational  tasks  to  be 
decomposed  into  tightly  coupled  jobs  executing 
concurrently  on  multiple  processing  resources. 

5.6  Systolic  Cellular  Array  Processor 

The  Systolic  Cellular  Array  Processor  (SCAP) 
is  the  latest  of  the  modular  processor 
components  in  the  Hughes  product  line.  It  is 
built  using  a  Single  Instruction  Multiple  Data 
Stream  (SIMD)  architecture.  A  single  module  of 
the  cuiTent  design  is  capable  of  performing  3.2 
billion  floating  point  operations  per  second.  The 
SCAP  has  been  designed  to  operate  with  the 
same  global  bulk  memory  interfaces  as  other 
Hughes  modular  products.  Figure  4  shows  air 
flow  through  tlie  Standard  Avionics  Module 
physical  configuration  that  exists  today. 
Hughes  plans  to  develop  a  Standard  Electronics 
Module  (SEM)  configuration  using  its  advanced 
large  panel  High  Density  Multichip  Interconnect 
(HDMI)  technology. 

5.7  Hughes  Modular  Products  (COTS) 

While  there  many  applications  where  the  highest 
component  density  possible  is  required,  as  in  the 
F-22,  there  are  other  applications  where 
advantages  can  be  gained  by  using  less  dense 
packaging  concepts.  Hughes  has  applied  the 
well  known  Versa  Module  European  (VME)  to 
the  1960  32-bit  CISC  processor  to  achieve  a  low 
cost  processor  module. 

5.7.1  Versa  Module  European 

While  there  are  many  available  back  plane  bus 
specifications  available,  the  one  that  is  receiving 
the  most  attention  in  the  commercial  avionics 
marketplace  is  the  VME.  The  VME  bus 
development  was  led  by  Motorola  in  the  late 
197()’s.  There  are  cuiTently  two  Institute  of 
Electrical  and  Electronic  Engineer  (IEEE) 
standards  which  define  the  bus  and  card 
interface.  IEEE  Standard  1014.1  is  the  VME 
bus  specification.  IEEE  Standard  1101.2 
defines  the  physical  characteristics  of  the 
Conduction  Cooled  Eurocard.  The  forum  for 
the  development  of  advances  to  these  standards 
is  the  VME  International  Trade  Association 
(VITA).  The  specification  to  expand  the 
interface  to  VME  64  is  cuirently  being  circulated 
for  approval  by  industry.  Processing  system 
components,  using  the  VME  fonnat,  are 


Figure  4.  The  Physical  Configuration  of  the  Present  SCAP  Air  Flow  Through  Standard  Avionics 
Module.  An  advanced  high  throughput  module  extends  performance. 


Figure  3.  Data  Processing  Module  Line  Replaceable  Module  Lay  out. 
Featuring  SEM-E  Format. 
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available  from  many  manufacturers.  Thus,  the 
VME  standards  provide  an  excellent  framework 
for  building  COTS  based  systems. 

Hughes  has  designed  an  advanced  processing 
module  using  the  64  VME  module  definition  and 
the  VME  64  back  plane  bus.  The  card  is  shown 
in  Figure  5.  The  card  uses  the  same  Multi-Chip 
Module  (MCM)  and  i960  processor  used  in  the 
HMP  applications  described  above.  By  using  a 
frequency  of  20  MHz,  the  power  dissipation  is 
kept  to  less  than  30  watts,  enabling  conduction 
cooling  to  be  used.  The  temperatures  are  low 
even  at  30  watts,  therefore  reliability  is  high. 
The  Software  Engineering  Environment  is  the 
same  used  for  the  F- 18  and  is  mature  and  widely 
available.  The  card  is  intended  for  retrofit 
applications  and  will  be  available  in  late  1995. 

The  on  module  interface  uses  the  PCI  bus 
definition.  This  means  as  future  developments  in 
CPU’s  occur,  they  may  be  substituted  on  the 
board  with  minimum  redesign. 

6.  LEGACY  SYSTEMS 

While  the  future  direction  of  avionics  systems  is 
undoubtedly  toward  higher  and  higher  levels  of 
integration,  the  dilemma  imposed  by  the  rapid 
advances  of  electronics  is  that  the  life  of  the 
current  aircraft  systems  is  thirty  to  fifty  years, 
even  longer  in  the  case  of  some  bombers  and 
tankers,  while  a  new  generation  of  data 
processors  appears  about  every  eighteen 
months.  Five  years  is  the  maximum  length  of 
time  that  a  commercial  manufacturer  expects  to 
continue  manufacturing  a  given  product. 

Parts  obsolescence,  while  always  a  problem, 
becomes  more  of  a  concern  in  this  environment. 
Advanced  technology  solutions  to  parts 
obsolescence  include  use  of  plastic  encapsulated 
microelectronics  (PEMS)  used  extensively  in 
commercial  applications  and  alternately 
mounting  bare  die  on  circuit  boards  that  use 
printed  wiring  that  can  accommodate  differences 
in  die  size  and  interconnects.  Processes  must 
include  practices  such  as  the  use  of  VHDL  that 
capture  design  detail  and  enable  ease  of 
transition  to  the  next  generation  technology. 
Another  major  issue  as  technology  upgrades  are 
pursued,  is  the  impact  on  the  existing  software. 
This  software  usually  represents  a  large 
investment  and  minimizing  the  changes  to  it  is 
usually  desired. 

Incremental  upgrades  may  be  the  affordable 
approach  taken  that  captures  existing  software 


and  necessary  infrastructure  but  moves  to  a 
more  open  architecture  and  enables  new 
functions  to  be  added  using  advanced 
technology.  It  is  against  this  background  that 


Figure  5,  Intel  i960  Processing  on  VME  with  a 
Mature  SAV  Engineering  Environment  (SEE) 


Hughes  has  developed  a  single  chip  upgrade  for 
its  MU  Std  1750  processor.  This  processor, 
originally  developed  by  Delco  Electronics,  is 
employed  in  processing  applications  in  the  F-16 
fire  control  computer,  the  Lantim  pod  computer, 
the  MADAR  computer  for  the  C-5,  and  the 
mission  computer  for  the  C-17.  The  single  chip 
version  replaces  the  original  twelve  chip 
computer  and  achieves  a  through  put  of  4  MIPS 
with  30  MHz  clock  speed.  Prototype  cards  in 
the  LANTIRN  Configuration  were  delivered  to 
Warner  Robins  AFB,  GA  for  evaluation  in 
August  1994.  The  software  developed  for  use 
in  the  previous  multichip  version  was  loaded 
and  successfully  run.  The  LANTIRN 
configuration  is  a  modified  4"  x  6"  card  (1/2 
ATR).  A  1/2  ATR  version  will  be  demonstrated 
in  an  F- 16  fire  control  computer  next  year.  This 
single  board  computer  is  illustrated  in  Figure  6. 

7.  CONCLUSION 

A  review  of  the  Hughes  processor  product  line 
indicates  a  broad  range  of  products  from  very 
high  peifonnance  and  innovative  designs  to 
those  systems  with  high  utUization  of  COTS. 
These  products  can  be  applied  over  the  spectrum 
of  required  performance  levels  through  module 
expansion  and  yet  retain  the  same  supporting 
architecture  and  infrastructure. 

The  products  applied  to  the  F-22  exemplify  the 
high  performance  products  where  issues  of  data 
security  and  packaging  for  extreme 
environments  have  been  addressed.  Adaptation 
to  commercial  practices  requires  that  designs  use 
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open  architectures  and  robust  designs  to  mitigate 
the  obsolescence  problems  due  to  faster 
technology  advances.  The  use  of  OS  and  COTS 
components  from  modules  to  components  to 
software  development  environments  needs  to  be 
increased  to  provide  the  lowest  cost  solution 
over  the  life  of  the  system  that  is  compatible 
with  the  overall  performance  requirements  of 
any  specific  weapons  system. 


smt- 
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Figure  6.  Magic  V  Single  Chip  MIL-STD-175() 
Single  Board  Computer  enabled  the 
incorporation  of  advanced  technology  yet 
capturing  the  previous  investment  in  software. 
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SUMMARY 

Daimler-Benz  Aerospace,  Ulm  has  developed  the 
Advanced  Programmable  Signal  Processor 
(APSP),  a  modular,  scaleable  and  programmable 
multi-Gigaflop  machine  based  on  studies  spon¬ 
sored  by  GMOD.  The  modular  architecture  allows 
an  easy  tailoring  to  quite  different  requirements  in 
signal  processing  and  pattern  recognition  for  Ra¬ 
dar,  Sonar,  Electro-optical  sensor  applications,  e.'g. 
from  small  non-coherent  radar  and  EW  systems  up 
to  sophisticated  airborne  multimode  pulse  doppler 
radars  or  complex  ground  or  ship  based  multi- 
channels  radars. 

From  an  architectural  point  of  view,  the  APSP 
comprises  clusters  of  single  chip  floating  point 
processors  (Texas  Instruments  TMS320C3x  [1] 
digital  signal  processor  which  can  perform  32-bit 
floating  point  calculations  at  a  60  Megaflop  rate), 
special  partially  programmable  modules  (based 
upon  off-the-shelf  VLSI-chips),  multipurpose 
memory  modules  and  multipurpose  interface 
modules.  The  APSP  comes  with  comprehensive 
Software  and  Tools  including  the  real  time  multi¬ 
processor  operating  system  APOS.  The  modularity 
and  scalability  in  Hardware  and  Software  offers 
the  possibility  to  tailor  the  signal  processor  per¬ 
formance  to  the  application,  while  preserving  op¬ 
tions  for  growth  potential.  Furthermore  modifica¬ 
tions  in  the  processing  algorithms  are  done  via 
software  changes,  without  costly  hardware  re¬ 
design. 

This  article  focuses  the  major  aspects  of  the  APSP 
in  Hardware,  Operating  System  and  Software 
Tools  and  shows  the  implementation  of  a  small 
and  a  high  performance  application. 
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Mega  (10®)  Floating-Point-Operations 

per  second 

Mass  Memory 

Operating  System 

Random  Access  Memory 

Synthetic  Aperture  Radar 

Signal  Processor 

Software 

Very  Large  Scale  Integration 


1.  INTRODUCTION 

GMOD  sponsored  studies  were  the  basis  for  the 
development  of  the  APSP,  a  modular,  scaleable 
and  programmable  signal  processing  system  de¬ 
veloped  for  a  wide  variety  of  signal  processing 
applications  e.g.  Radar,  EW,  EO  sensors.  Sonar,., 
in  ground-based  and  airborne  systems. 

The  APSP  is  designed  as  a  complete  signal  proc¬ 
essing  system  with  five  layers  as  Fig.  1-1  shows. 
The  top  layer  is  represented  by  the  application 
which  is  mapped  by  means  of  the  layers  below  to 
the  bottom  layer,  which  is  the  APSP  hardware. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems",  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 


20-2 


The  APSP  is  designed  as  a  hierarchically  coupled 
multi  processor  system,  that  can  be  simply  adapted 
to  performance  requirements  between  300 
MFLOPS  and  several  GFLOPS.  The  APSP  pro¬ 
vides  fail-soft  capability  by  parallel  processing, 
single  instruction  multiple  data  (SIMD)  and  mul¬ 
tiple  instruction  multiple  data  (MIMD)  perform¬ 
ance  and  has  a  long-term  architecture  with  high 
growth  capability.  The  APSP  is  programmable  in 
'C,  provides  a  user-friendly  operating  system  that 
supports  application  programming  without  special 
knowledge  of  hardware  and  comes  with  system 
configuration  tools  to  simplify  the  distribution  of 
application  to  the  hardware. 


Application 

Development  Environment 

Tools 

Operating  System 

Executable  Code 

APSP  Hardware 

Fig.  1-1  APSP  System  Architecture 


2.  APSP  Hardware 

The  APSP  can  be  seen  like  a  box  of  building 
blocks  that  are  taken  to  adapt  the  APSP  hardware 
to  application  requirements.  The  smallest  building 
block  is  a  module.  All  modules  are  realised  as 
Double  Eurocards  (233  x  160  mm).  All  modules 
are  available  in  a  commercial  version  (0°C  to 
+70°C)  and  a  ruggedized  version  (-40°C  -  +85°C). 

The  APSP  is  built  up  with  two  kind  of  modules, 
see  Fig.  2-1, 

•  APSP  modules 

•  VMEbus  modules 

The  APSP  modules  perform  the  signal  processing 
functions  These  modules  communicate  via  the 
Data  Transfer  Network  (DTN)  using  a  message 
passing  protocol.  Two  versions  of  the  DTN  are 
available: 

1 .  A  32  Bit  Bus  with  40  Mbytes/sec  data  rate  for 
lower  performance  systems. 


2.  A  Star  topology  with  8  nodes,  allowing  4  simul¬ 
taneous  point-to-point  connections  for  high  per¬ 
formance  systems.  The  maximum  data  rate  is 
280  Mbytes/sec. 


Fig.  2-1  APSP  Block  Diagram 


The  APSP  modules  are  subdivided  in  two  groups, 
fully  programmable  and  special  partly  program¬ 
mable  modules  (SPPM).  Fully  programmable 
modules  are  based  on  clusters  of  programmable 
signal  processors  TMS320C3x  from  Texas  Instru¬ 
ments  [1]  and  provide  the  greatest  flexibility. 
SPPMs  contain  dedicated  processing  hardware, 
e.g.  FFT  processor,  to  achieve  a  very  high  per¬ 
formance  by  executing  a  limited  number  of  proc¬ 
essing  functions  with  limited  flexibility. 

The  VMEbus  has  a  twofold  role  in  the  APSP: 

1 .  It  serves  as  the  Local  Control  Bus  of  the  APSP. 
By  means  of  an  off-the-shelf  VMEbus  CPU, 
called  Master  Controller  (MC),  the  APSP 
modules  are  controlled  and  monitored. 

2.  It  supports  the  extension  of  the  APSP  by  off- 
the-shelf  VMEbus  modules,  e.g.  SCSI  Inter¬ 
face,  Graphics  controller  etc. 

The  following  APSP  modules  are  available: 

•  Processing  Element,  the  basic  module  of  the 
APSP. 

•  General  Purpose  Input/Output  (GPIO),  is  used 
to  build  clusters  of  PEs. 

•  Doppler  Processor  (DOP),  is  a  special  partly 
programmable  module  for  dedicated  high  per¬ 
formance  signal  processing  functions 

•  Mass  Memory  (MM),  provides  additional 
memory  area  of  16  Mbytes  RAM. 
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•  DTN  Star  Controller,  connects  up  to  8  DTN 
nodes  and  performs  point-to-point  (  4  pairs), 
multicast  and  broadcast  communication. 

•  APSP  Serial  Input/Output  (APSP-SIO),  pro¬ 
vides  the  input/output  interface  to  a  frontend. 

•  Master  Controller  (MC),  supervises  the  APSP 
modules.  It  is  a  general  purpose  VMEbus  Sin¬ 
gle  Board  Computer  based  on  the  Motorola 
68040  processor. 

2.1  Processing  Element  (PE) 

The  Processing  Element  is  the  basic  module  in  the 
APSP  system.  It  contains  five  TMS320C3x  [1] 
Digital  Signal  Processor  (DSP),  see  Fig.  2-2.  Each 
can  perform  32-bit  floating  point  calculations  at  a 
60  MFLOP  rate,  that  gives  an  overall  performance 
of  300  MFLOPS. 

One  DSP  is  used  as  Local  Controller  (LC)  for 
flexible  control  of  the  PE  e.g.  housekeeping,  I/O 
data  transfer,  MC  communication,  etc.  The  four 
other  DSPs  act  as  servers  that  are  subdivided  into 
two  couples  connected  via  a  shared  32-bit  bus  to  a 
memory  bank  of  1  MBytes. 

All  internal  busses  of  the  PE  are  connected  to  the 
4-port  crossbar  switch,  that  allows  two  simultane¬ 
ous  point-to-point  connections.  The  PE  has  two 
interfaces:  The  DTN  Node  handles  communication 
with  the  DTN.  Via  the  VMEbus  the  MC  has  ac¬ 
cess  to  the  onboard  RAMs. 


Fig.  2-2  Processing  Element  Block  Diagram 

2.2  General  Purpose  Input  /  Output  (GPIO) 

The  GPIO  is  used  to  connect  up  to  four  PE  mod¬ 
ules  without  interfering  the  DTN.  Furthermore  it 
connects  the  PE  with  the  VMEbus  and  provide 
additional  RAM  for  the  PE.  It  contains  1  DSP 
processor  TMS320C3 1  as  LC  for  flexible  control 


of  the  GPIO  e.g.  housekeeping,  I/O  data  transfer, 
BIT  etc.,  see  Fig.  2-2. 


FIG.  2-2  GPIO  Block  Diagram 

The  GPIO  has  four  interfaces:  The  DTN  Node 
handles  communication  with  the  DTN.  The  EX- 
busO  and  EXbusl  interfaces  connect  the  PEs  to 
form  a  Programmable  Processing  Module  (PPM), 
se  Fig.  2-3  The  VMEbus  interface  gives  the  Mas¬ 
ter  Controller  access  to  at  all  RAMs  in  the  GPIO 
and  the  connected  PEs. 

All  internal  busses  of  the  PE  are  connected  to  the 
4-port  crossbar  switch,  which  allows  two  simulta¬ 
neous  point-to-point  connections  (e.g.  DTN  with 
RAMO  and  VMEbus  with  RAMI). 


VMEbus 


FIG.  2-3  Programmable  Processing  Module 


2.3  Doppler  Processor  (DP) 

The  Doppler  Processor,  see  Fig.  2-4,  is  a  special 
partly  programmable  module  dedicated  to  high 
performance  signal  processing  functions  like  FFT, 
Fast  Convolution,  Complex  multiply,  Magnitude 
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square  calculation.  The  FFT  processor  is  a  Sharp 
LH9412Y-33  [2]  providing  400  MFLOPS  of  24-bit 
block  floating  performance.  The  FFT  processor  is 
connected  to  three  48-bit  memory  banks,  RAMA 
with  a  capacity  of  256  Kwords,  RAMB  and  C  with 
128  Kwords  each,  to  give  an  optimal  support  for 
the  multi-pass  architecture  of  the  LH9412Y-33.  So 
a  performance  is  achieved  for  complex  FFT  of  1 00 
ps  for  IK  points  and  374  ps  for  4K  points. 


Fig.  2-4  Doppler  Processor  Block  Diagram 


The  DP  contains  also  one  DSP  TMS320C3 1  [1]  as 
Local  Controller  (LC)  for  flexible  control,  e.g. 

FFT  kernel  control,  DTN  protocol  handling  and 
post-processing  functions.  The  LC  RAM  has  a 
capacity  of  5 12  Kbytes.  The  DP  has  two  DTN 
interface  to  support  flow-through  processing  with 
a  max.  throughput  of  5.5  Megasamples/sec  of  16 
bit  complex  data. 

2.4  Mass  Memory  (MM) 

The  Mass  Memory  provides  additional  memory 
area  of  16  Mbytes  RAM,  see  Fig.  2-5.  It  is  acces¬ 
sible  via  two  independent  DTN  Interfaces  and  the 
VMEbus.  The  MM  is  also  equipped  with  a 
TMS320C31  processors  as  Local  Controller  that 
performs  flexible  addressing,  e.g.  comer  turning, 
and  signal  processing  tasks  on  the  memory  content 
e.g.  CFAR  computation  without  interfering  a  PE. 
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Fig.  2-5  Mass  Memory  Block  Diagram 

2.5  Data  Transfer  Network  (DTN) 

The  Data  Transfer  Network  is  a  high  performance 
network  to  exchange  data  between  APSP  modules. 
It  is  designed  for  communication  in  asynchronous 
parallel  multiprocessing  systems.  The  basic  DTN 
cluster  is  implemented  by  a  star  topology  in  which 
all  nodes  are  linked  via  a  central  switch(Crossbar) 
which  transfers  the  data  according  to  the  central 
control  system,  the  DTN  Star  controller,  see  Fig. 
2-6. 


Node 

Node 

APSP 

Module 

'  7'  DTN  'X ' 

Star  Controller 

APSP 

Module 

Node 

Node 

APSP 

_ 1 _ 

Node 

APSP 

Module 

APSP 

Module 

Module 

FIG.  2-6  DTN  Configuration 


The  DTN  Star  Controller  handles  the  data  and 
control  transmission  within  the  DTN  see  Fig.  2-7. 
The  Star  Controller  analyses  requests  for  commu¬ 
nication  from  the  nodes,  manages  the  data  path 
switching  and  reports  transfer  errors.  The  Star 
Crossbar  Switch  connects  the  data  paths  in  the 
network  according  to  the  settings  from  the  Star 
Controller. 


The  Star  Monitor  traces  the  DTN  activities  and 
permits  the  Master  Controller  to  monitor  and  con¬ 
trol  the  DTN  behaviour  via  a  serial  link. 
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Serial  Line 


DIN  DTN 


FIG.  2-7  DTN  Star  Controller  Block  Diagram 

2.6  APSP  Serial  Input  /  Output  (APSP-SIO) 

The  APSP  Serial  Input  /  Output  is  used  to  connect 
the  APSP  with  front-ends,  see  Fig.  2-8.  The  com¬ 
munication  is  performed  by  TAXI  links  realized 
with  AMD  components  Am7969/68-125.  Two 
TAXI  links  transfer  data  from  the  front-end  to  the 
APSP-SIO  to  achieve  a  data  rate  of  22  Mbytes/sec. 
Data  to  the  front-end  are  transfer  via  one  TAXI 
link  which  give  a  data  rate  of  1 1  Mbytes/sec. 

The  APSP-SIO  contains  also  1  DSP  processor 
TMS320C30  as  Local  Controller  (LC)  for  flexible 
control  of  the  APSP-SIO,  e.g.  housekeeping,  TAXI 
I/O  data  management,  DTN  protocol  handling, 
BIT,  etc.  The  output  of  the  TAXI  Receiver  are  fed 
to  FIFOs.  The  output  of  the  FIFO  are  read  by  the 
LC  via  the  Data  Packer.  The  Data  Packer  handles 
different  FIFO  access  modes  to  achieve  optimal 
speed  for  data  transfer,  e.g.  simultaneous  read  of 
both  FIFOs  and  output  of  one  16-Bit  word  per  LC 
access  or  double  read  of  FIFOs  and  output  one  32- 
Bit  word  per  LC  access. 


3.  APSP  Software 

All  phases  of  the  application  development  for  the 
APSP  are  supported  by  a  comprehensive  set  of 
tools,  refer  to  fig.  3-1. 

The  aim  of  the  SYSTEM  MODELLING  PHASE 
is  the  development  of  the  processing  algorithms. 
This  is  done  on  a  Host  platform  (Sun,  IPM  PC) 
and  supported  by  off-the-shelf  mathematical  and 
graphical  SW-packages,  like  PV  Wave  from  Pre¬ 
cision  Visuals. 

In  the  SYSTEM  SIMULATION  PHASE  an 
overall-simulation  of  the  processing  is  required. 
The  data  driven  simulation  (e.g.  PTOLEMY)  fits 
best  to  the  signal  processing  philosophy. 


FIG.  3-1  APSP  Software  Environment 


In  the  PROGRAM  GENERATION  PHASE  the 
HOL  algorithms  are  surrounded  by  APOS  system 
calls.  For  time-critical  sections  APSP-LIB  func¬ 
tions  are  inserted.  The  physical  distribution  of 
processes  and  data  are  managed  by  the  System 
Configuration  Tool. 

INTEGRATION  AND  TEST  is  strongly  sup¬ 
ported  by  the  APSP-BUG  multi-processor  debug¬ 
ger.  It  provides  control  and  insight  view  to  each 
DSP  of  the  system. 


3.1  Operating  System 

The  APSP  Operating  System  APOS  is  especially 
developed  to  meet  the  requirements  of  signal  proc¬ 
essing.  It  provides  a  low  system  overhead,  fast 
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interrupt  response  time  and  short  process  switch 
time.  Less  than  300  words  of  the  DSP’s  on-chip 
RAM  are  occupied  by  the  OS. 

APOS  provides  the  following  main  objects  for 
processing  and  communication: 

•  Mailboxes 

•  Processes 

•  Messages 

The  processing  algorithms  are  embedded  into 
Processes.  Data  are  transferred  as  Messages  be¬ 
tween  processes  and  Mailboxes.  Processes  are 
coupled  by  means  of  mailboxes.  Each  process  has 
at  least  one  input-  and  one  output-  mailbox.  A 
process  is  activated  by  the  scheduler,  when  its 
input-mailbox  contains  data.  After  processing,  the 
results  are  stored  in  an  output-mailbox.  This  acti¬ 
vates  the  subsequent  process(es). 

All  these  features  are  especially  useful  for  realis¬ 
ing  complex  data  distribution  schemes.  As  indi¬ 
cated  by  Fig.  3-2  several  connection  schemes  of 
processes  and  mailboxes  are  possible.  For  example 
a  mailbox  may  be  consumed  by  several  processes, 
the  data  of  several  processes  may  be  combined  in  1 
mailbox. 


code,  data  etc.  This  specification  can  be  done  in  a 
high  level  syntax.  The  Process  Configuration 
Tool  takes  this  file  and  generates  the  correspond¬ 
ing  linker  command  file. 

In  the  Mode  Definition  File  the  allocation  of  proc¬ 
esses  to  DSPs  and  the  connection  of  mailboxes  to 
processes  are  defined.  This  is  done  in  a  C-style 
syntax.  The  Mode  Configuration  Tool  extracts 
the  information  from  the  Mode  Definition  File  and 
generates  the  appropriate  system  tables  for  the 
APOS. 


— 


PROCESS  2  h 


PROCESS  3  M 


r>(MBx)— J 


II 

1 

Fig.  3-1  Process  Configuration  Example 

Such  a  communication  scheme  is  independent  of 
the  process  location.  If  the  communicating  proc¬ 
esses  are  allocated  on  the  same  module,  the  mail¬ 
boxes  are  realised  as  buffers  in  the  module’s 
memory  area.  If  the  processes  are  distributed 
among  different  hardware  modules,  the  access  to 
an  off-module  mailbox  is  routed  automatically  via 
the  DTN. 

3.2  System  Configuration  Tool  Set 

The  multi  processor  characteristics  of  the  APSP 
needs  an  extended  support  for  system  configura¬ 
tion  and  debugging. 

For  the  definition  of  a  process,  the  programmer 
generates  a  Process  Configuration  File  which 
contains  information  concerning  the  allocation  of 


Fig.  3-2  Program  Development  Flow 

The  APSP-BUG  is  an  essential  tool  for  testing  and 
integrating  the  application  software.  It  offers  the 
ability  to  observe  and  manipulate  all  memories  and 
processors  in  the  APSP  system. 

The  Debugger  is  controlled  from  a  Host  computer 
(PC  or  SUN  Sparc  station)  by  means  of  a  window 
oriented,  menu  controlled  User  Interface.  Provi¬ 
sions  on  the  processing  hardware  are  made  to  gen¬ 
erate  system-wide  breakpoints.  When  a  processor 
reaches  a  breakpoint,  all  other  DSPs  in  the  system 
are  halted.  This  freezes  the  current  system  state  for 
analysis. 

4.  Implementation  of  Applications 

4.1  Implementation  Steps 

The  first  step  of  implementing  an  algorithm  on  the 
APSP  is  to  generate  a  simulation  program  in 
ANSI-‘C’  running  on  a  general  purpose  host.  For 
test  and  verification  purpose  synthetic  or  recorded 
flight  trial  data  are  used  as  input  data. 

The  porting  of  the  program  to  a  single  DSP  system 
is  done  in  the  next  step  of  the  algorithm  implemen¬ 
tation.  After  verification  of  the  real-time  behaviour 
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of  the  processing,  the  time  critical  sections  are 
replaced  by  off-the-shelf  or  proprietary  optimised 
library  routines. 

In  the  final  step  the  processing  is  allocated  to  the 
different  processing  modules  of  the  APSP. 
Processes  which  are  running  on  Processing  Ele¬ 
ments  are  extended  by  APOS  system  calls  in  order 
to  implement  resource  sharing  and  inter  processor 
communication  functions. 

Processes  that  are  running  on  a  Doppler  Processor 
are  modified  by  substituting  the  vector  and  FFT 
processing  functions  with  appropriate  sub-routine 
calls  which  utilise  the  FFT  hardware. 

4.2  Hardware  Mapping  of  the  Application 

Three  major  APSP  modules  are  involved  in  an 
example  for  a  small  performance  solution,  the  so- 
called  ISAR  Processing  Unit  (IPU),  refer  to  Fig.  4- 
1 .  This  unit  is  used  in  an  air  maritime  airborne 
surveillance  radar  for  ship  classification.  It  allows 
real-time  processing  of  ISAR  images  with  resolu¬ 
tion  of  some  meters  and  more  then  2x10^ 
pixels. 

The  IPU  gives  a  performance  of  700  MFLOPS. 


Fig.  4-1  ISAR  Processor  Unit 
The  involved  APSP  modules  are: 


A  challenging  high  performance  application  of  the 
APSP  is  presented  in  Fig.  4-2.  It  shows  the  block 
diagram  of  a  real-time  SAR  processor  for  medium 
and  high  resolution  SAR  imaging  with  up  to 
50x10^  pixels  and  one  foot  resolution.  Digital 
pulse  compression  with  high  band-width-time 
product  waveforms,  range  gate  migration  and  cur¬ 
vature  correction  and  autofocus  require  different 
types  of  data  flow  and  processing. 

The  use  of  eight  Doppler  Processors  reflects  the 
intensive  use  of  FFT  processing  for  range  and 
azimuth  compression.  The  high  need  for  memory 
function,  which  is  typically  for  a  sophisticated 
mapping  mode,  is  met  by  Mass  Memories  with  a 
total  of  64  Mbytes  in  addition  to  the  approximate 
40  Mbytes  memory  capacity  distributed  over  the 
SAR  processor.  The  complete  SAR  processor 
consists  of  20  boards  and  covers  the  processing 
requirements  for  four  complete  different  SAR 
modes 

The  overall  performance  of  the  SAR  processor  is 
approx.  5  GFLOPS. 


Fig.  4-2  SAR  Processor  Unit 


The  Mass  Memory  is  used  for  buffering  the  in¬ 
coming  data  stream  from  the  Analogue/Digital 
Converter  and  for  processing  of  intermediate  re¬ 
sults. 

The  Doppler  Processor  performs  the  ISAR  pre¬ 
processing  steps  (Motion  Estimation  Motion 
Compensation  and  Prefocus),  for  algorithm  details 
refer  to  [3]. 

The  DSPs  on  the  Processing  Element  share  the 
data  pre-processed  by  the  DP  and  perform  the  im¬ 
age  processing  functions  of  the  ISAR  algorithm. 
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A  SURVEY  OF  ADVANCED  INFORMATION  PROCESSING  (AlP)  TECHNOLOGY  AREAS  FOR 

CREW  ASSISTANT  SYSTEM  DEVELOPMENT* 

S.  Kuru 

H.  L.  Akin 

Department  of  Computer  Engineering,  Bogazi^i  University,  80815,  Bebek-lstanbul,  TURKEY. 
Summary 

In  this  survey,  carried  out  within  the  framework  of  EUCLID  RTP  6.5  CREW  ASSISTANT  project,  the 
following,  Advanced  Information  Processing  (AIP)  technology  areas  were  surveyed:  Software  Engineering, 
Knowledge-Based  Systems,  Distributed  Artificial  Intelligence,  Learning  Systems,  Planning,  Model-Based 
Reasoning,  Case-Based  Reasoning,  and  Object-Oriented  Databases.  The  survey  evaluated  the  AIP  technology 
areas  with  respect  to  the  a  predetermined  set  of  criteria.  The  following  criteria  were  used:  Functionality 
Reliability,  Performance,  Modularity,  Integration  with  other  technologies.  Engineering  methodology.  Maturity 
and  next  generation,  and  Availability  within  consortium.  The  main  findings  are:  AIP  technologies  have  a  high 
degree  of  applicability  in  the  A  in  general.  The  current  state  of  the  art  in  AIP  technologies  is  at  a  mature  level  to 
offer  acceptable  solutions  for  the  Crew  Assistant  development.  It  can  be  said  that  basically  all  of  the  AIP 
technologies  investigated  may  be  employed  in  some  way  in  the  CA  development. 


1.  Introduction 

This  survey  was  prepared  within  the  framework  of  EUCLID  RTP  6.5  CREW  ASSISTANT  project  under  a 
contract  awarded  to  a  consortium  consisting  of  Aienia,  Bogazifi  Universitesi,  DASA  and  NLR  (SLIE)  in  the 
context  of  the  EUCLID  program  under  control  of  the  CEPA  6. 

The  EUCLID  CEPA-6  Crew  Assistant  (CA)  programme  is  defined  with  the  following  objectives  [1]: 

1 .  Demonstrate  that  the  concept  of  a  crew  assistant  for  military  aircraft 

a)  meets  the  needs  of  operational  missions  of  the  year  2000  and  beyond,  and 

b)  improves  mission  capability  in  a  cost  effective  manner; 

2.  Define  a  common  European  CA-concept; 

3.  Promote  necessary  Advanced  Information  Processing  (AIP)  techniques  applicable  to  this  CA-concept; 

4.  Establish  a  proper  methodology  for  knowledge  engineering  among  the  European  aerospace  community  in 
order  to  allow  future  joint  production  of  Ca-systems. 

The  Crew  Assistant  (CA)  program  will  combine  traditional  technologies  with  AIP  technologies.  Therefore  a 
survey  of  the  current  state  of  the  art  of  the  AIP  technologies  was  needed  to  provide  a  starting  basis.  This  survey 
collects  the  feasible  approaches  as  currently  known  and  evaluates  their  applicability  for  the  CA  program 

The  AIP  technology  areas  considered  are: 

•  Software  Engineering, 

•  Knowledge-Based  Systems, 

•  Distributed  Artificial  Intelligence, 

•  Learning  Systems, 

•  Planning, 

•  Model-Based  Reasoning, 

•  Case-Based  Reasoning,  and 

•  Object-Oriented  Databases. 


*  This  work  was  supported  partially  by  Turkish  Ministry  of  Defense  and  by  Bogazi9i  University  Research  Fund 
(Project  No:94A0 1 08). 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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2.  Methodology  for  AIP  technology  survey 

AlP  technology  survey  was  conducted  in  three  main  steps: 

1 .  identification  of  technology  areas  to  be  evaluated  and  distribution  among  partner  Industrial  Entities  (lEs), 

2.  determining  evaluation  criteria  and  a  framework  for  evaluation, 

3.  evaluation  of  each  technology  area  by  the  responsible  IE. 

The  results  of  the  evaluation  of  each  technology  area  were  combined  to  produce  a  recommendation  for  the  CA 
development. 

AIP  technology  areas  to  be  evaluated  were  identified  using  a  data  form  to  collect  proposals  from  partner  lEs.  The 
data  form  has  entries  specifying: 

•  the  proposed  area, 

•  relevance  to  CA, 

•  an  indication  of  the  importance  of  the  area, 

•  evaluation  criteria  and  techniques, 

•  estimated  total  effort  needed  for  evaluation,  and 

•  availability  of  expertise  at  lEs. 


The  evaluation  framework  is  based  on  the  identification  of  the  issues  implied  by  each  criterion  and  the  aspects  of 
the  AIP  technology  area  relevant  to  the  CA  and  to  each  criterion.  It  is  assumed  that  the  evaluation  is  a  subjective 
evaluation  expressed  mostly  in  terms  of  a  discussion  of  the  relevant  issues. 

2.1  Evaluation  criteria  for  AIP  technology  areas 

The  criteria  used  in  the  evaluation  of  the  generic  AIP  technology  areas  include: 

•  Functionality, 

•  Reliability, 

•  Performance, 

•  Modularity, 

•  Integration  with  other  technologies, 

•  Engineering  methodology, 

•  Maturity  and  next  generation,  and 

•  Availability  within  consortium. 


These  criteria  and  evaluation  with  respect  to  these  criteria  are  discussed  below. 

2.1.1  Functionality 

Functionality  relates  the  subject  area  of  a  particular  AIP  technology  area  to  the  functions  of  the  CA  application 
areas.  Functionality  is  best  expressed  in  terms  of  a  matrix  of  CA  application  areas  versus  the  capabilities  / 
services  provided  by  the  AIP  technology  area.  In  this  matrix,  an  entry  shows  that  the  particular  AIP  capability  is 
applicable  to  the  corresponding  CA  application  area.  Functionality  is  investigated  at  two  levels: 

•  Applicability  to  CA  in  general 

•  Applicability  to  specific  application  areas  in  particular 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  List  the  functionalities  of  the  AIP  technology  area  (i,e.,  services/facilities  provided  by  the  area) 
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•  Discuss  each  functionality,  by  giving  a  definition,  and  if  relevant,  by  identifying  the  sub-functionalities 

•  Identify  functions/requirements  of  the  CA 

•  Make  a  matrix  (i.e.  a  table)  of  CA  functions  versus  functionalities  of  the  AlP  technology  area,  where  an  entry 
in  the  matrix  denotes  that  the  AlP  functionality  may  be  used  in  some  way  in  the  implementation  of  the  CA 
function,  and  discuss  relevant  issues  for  each  entry 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 

2.1.2  Reliability 

For  each  AlP  technology  area,  the  reliability  criterion  relates  the  reliability  of  the  resulting  CA  to  the  particular 
AIP  technology  area  used.  Reliability  is  investigated  in  two  dimensions: 

•  Verification,  Validation  and  Certification  (V,  V  and  C) 

•  Impact  on  flight  safety 

From  the  point  of  view  of  reliability,  V,  V  and  C  is  related  to  whether  there  are  proper  V,  V  and  C 
techniques/methods  available  to  use  for  the  particular  AIP  technology  area,  and  if  so,  the  impact  of  these 
techniques/methods  on  the  reliability  of  the  CA. 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  Identify  those  functions  of  the  CA  that  are  sensitive  in  terms  of  reliability 

•  Discuss  the  reliability  of  the  CA,  as  a  whole  and  at  application  area  and  functions  levels,  when  a  particular 
AIP  technology  area  is  utilized  in  the  development  of  the  CA 

•  Discuss  techniques/methods  of  Verification,  Validation  and  Certification  (V,  V  and  C)  with  respect  to 
application  areas  and  with  respect  to  integration  of  V,  V  and  C  into  the  engineering  methodologies  to  be 
employed 

2.1.3  Performance 

Performance  of  both  the  AIP  technology  area  itself  and  the  resulting  CA  are  considered.  Performance  is 
investigated  in  two  dimensions: 

•  Timeliness 

•  Real-time  behavior 

Timeliness  is  the  time  performance  of  the  AIP  technology  area  (i.e.  the  performance  of  techniques/methods  used, 
tools  available)  or  the  CA  developed.  Timeliness  is  evaluated  in  terms  of  the  speed  of  processing  (i.e.  fast  or 
slow),  bounded  response  time  (i.e.  response  is  guaranteed  within  a  given  limit  of  time),  and  any-time  response 
(i.e.  capability  of  having  an  answer  at  all  times). 

Real-time  behavior  issues  include  focus  of  attention  and  asynchronicity,  etc. 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  Discuss  in  general  time  performance  (i.e.  speed  of  processing,  bounded  response  time,  guaranteed  response, 
any-time  response,  etc.)  of  systems/applications  employing  the  AIP  technology  area 

•  Discuss  in  particular  at  CA  functions/requirements  level  the  expected  time  performance  of  resulting  systems 

•  Discuss/name  the  techniques/methods  to  achieve  bounded  response  time,  guaranteed  response  and  any-time 
response  from  the  AIP  technology  area 

•  Discuss  in  general  real-time  behavior  (i.e.  focus  of  attention,  asynchronicity,  etc.)  and  in  particular  techniques 
used  for  the  AIP  technology  area 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 

2.1.4  Modularity 

Modularity  is  related  to  whether  a  particular  system  is  composed  of  interacting  modules.  An  AIP  technology  area 
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may  or  may  not  be  able  to  support  modularity.  In  other  words,  it  may  or  may  not  be  possible  to  develop  a 
modular  system,  depending  on  the  particular  AIP  area.  Modularity  has  two  very  important  implications  on  the 
resulting  system; 

•  Scalability 

•  Maintainability 

Scalability  means  the  possibility  of  scaling  up  a  small  scale  system  without  requiring  to  redo  the  work  done  for 
the  small  scale  system.  Scalability  is  related  to  economy  in  one  hand  and  to  ease  (i.e,  complexity)  of  system 
development  on  the  other. 

Maintainability  is  related  to  the  ease  of  making  changes  and  improvements  in  a  system  at  the  operation  phase  (i.e. 
while  it  is  in  use)  of  its  life  cycle.  Maintainability  is  also  an  economy  issue. 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  Discuss  in  general  whether  the  particular  AIP  technology  area  supports  (or,  is  suitable  for)  modularity  and 
modular  system  development  Identify  the  basic  elements  (i.e.  components)  used  in  defining  modules 

•  Identify  techniques/methods  used  in  decomposing  a  large  system  into  modules 

•  Discuss  scalability  issues  (i.e.  whether  this  is  possible,  how  costly  it  is,  etc.) 

•  Discuss  maintainability  issues  (i.e.  maintainability  problems  known,  cost  of  maintenance,  etc.) 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 

2.1.5  Integrability 

Integrability  refers  to  the  possibility  of  integration  of  an  AIP  technology  with  other  technologies  in  developing  a 
system.  Integrability  is  related  to  modularity  and  the  availability  of  modular  components  with  standard  interfaces. 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  Discuss  in  general  the  possibility  and  ease  of  integrating  the  particular  AIP  technology  with  other 
technologies 

•  If  possible,  discuss  integration  issues  (e.g.  architectural  issues,  communication  and  interfacing,  need  for 
developing  new  HW/SW  modules,  etc.) 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 

2.1.6  Engineering  methodology 

Engineering  methodology  criterion  has  two  aspects  within  the  framework  of  AIP  technology  evaluation  for  CA 
development: 

•  Availability  of  an  engineering  methodology 

•  Impact  on  life  cycle 

Availability  of  an  engineering  methodology  refers  to  whether  there  is  a  precise  and  well-defined  set  of 
techniques,  methods  and  tools  to  use  in  developing  a  system  using  the  particular  AIP  area.  Impact  on  life  cycle 
deals  with  the  ways  system  development  using  the  particular  AIP  technology  affects  the  life  cycle  approach  to 
system  development. 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area: 

•  Identify  the  availability  of  any  engineering  methodology  applicable  to  the  particular  AIP  technology  area, 
giving  a  brief  description  of  each  of  the  available  methodologies  (i.e.  overall  approach,  type  of  methodology, 
major  steps  or  activities,  main  techniques,  methods  and  tools,  etc.) 

•  Discuss  the  implication  of  using  a  functional  approach  or  an  object-oriented  approach  in  CA  development 
with  respect  to  the  methodologies  used  for  the  particular  AIP  technology  area 

•  Discuss  how  the  engineering  methodologies  available  for  the  AIP  area  would  affect  the  life  cycle  of  CA  (i.e. 
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cost  of  system  development,  ease  and  cost  of  maintenance,  etc.) 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 

2.1.7  Maturity  and  next  generation 

Maturity  and  next  generation  are  related  to  the  state  of  the  art  of  the  particular  AIP  technology  area. 

Maturity  can  be  expressed  in  terms  of  whether  the  AIP  area  is  yet  a  research  topic,,  or  a  prototype  system  has 
been  developed  employing  the  particular  AIP  technology  area,  or  there  is  an  operational  system  available. 
Another  indicator  is  the  availability  of  commercial  tools  to  support  system  development  using  the  AIP  area  (i.e. 
tools  implementing  methods  and  techniques  of  the  area  or  support  tools). 

Next  generation  refers  to  what  can  be  expected  from  the  particular  AIP  technology  area  in  the  (near)  future. 

Another  criterion  related  to,  maturity  is  embeddability  (i.e.  the  embeddability  into  CA  of  a  component  developed 
using  a  particular  AIP  'technology  area  -in  other  words  whether  it  is  possible  with  respect  to  hardware  limits  to 
embed  a  particular  AIP  technology  into  an  aircraft  as  a  hardware  or  software  component). 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area; 

•  Discuss  the  state  of  the  art  of  the  AIP  technology  area  in  terms  of  whether  it  is  yet  a  research  topic,  or  a 
prototype  system  is  available,  or  an  operational  system  is  available,  giving  example  systems  if  possible 

•  Discuss  the  availability  of  commercial  tools  to  support  the  AIP  technology  area,  if  possible  by  naming  and 
giving  the  main  properties  of  the  tools  available 

•  Discuss  if  any  major  development  is  expected  in  the  area  in  the  near  future 

•  Discuss  the  embeddability  of  a  component  developed  using  the  particular  All'  technology  into  CA  (i.e. 
whether  this  is  technically  possible  and  feasible,  whether  there  are  already  HW/SW  available  to  embed  such 
components  into  the  aircraft  as  a  CA  module  or  component,  etc.) 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 


2.1.8  Availability  within  consortium 

Availability  within  consortium  is  evaluated  in  two  dimensions; 

•  Availability  of  expertise 

•  Availability  of  tools  etc.  related  to  the  AIP  technology  area  on  the  HW/SW  platforms  available  within  the 
consortium 

Evaluation  with  respect  to  this  criterion  is  done  in  terms  of  a  discussion  addressing  the  following  issues  within 
the  context  of  the  AIP  technology  area; 

•  Discuss  whether  expert  knowledge  is  available  within  the  consortium,  stating  where  it  is  available 

•  Identify  AIP  technology  area  related  tools  within  the  consortium,  giving  main  properties,  platform  on  which  it 
is  available,  etc.  for  each  of  them 

•  Give  strong  and  weak  points  of  the  AIP  technology  area  with  respect  to  the  criterion 


3.  Results  of  Evaluation 

A  summary  of  the  evaluation  of  each  of  the  AIP  technology  areas  is  given  below. 

3.1  Software  Engineering  Methodologies 

Software  engineering  is  the  technological  and  managerial  discipline  for  the  systematic  production  and 
maintenance  of  software  products  that  are  developed  and  modified  on  time  and  within  cost  estimates  [2]. 
Software  .  engineering  is  concerned  not  only  with  technological  aspects  but  also  with  management  problems. 
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Software  engineering  technology  is  at  a  mature  state  offering  many  alternative  methodologies.  The  functional 
approach  is  well  understood  and  well  equipped.  The  object-oriented  approach,  although  new,  offers  many 
advantages  in  modeling  the  real  world,  and  in  maintainable  and  reusable  software  development.  It  is  expected 
that  both  approaches  are  to  be  used  at  different  stages  of  the  CA  development. 

3.2  Verification,  Validation  and  Certification 

Verification  and  validation  of  technologically  advanced  software  (such  as  KBS,  and  AlP  software  in  general)  is 
often  considered  to  be  more  difficult  than  V&V  of  traditional  software.  Nonetheless,  the  V&V  process  can  be 
supported  enormously  by  stepwise  refinement  of  the  requirements  to  the  implementation  and  by  documenting  all 
steps  taken.  The  need  for  correct  requirements  is  of  the  utmost  importance,  and  it  should  also  be  noted  that 
requirements  can  (and  often  do)  change  during  the  development  process  [3]. 

The  development  process  of  Crew  Assistant  software,  although  it  is  to  be  developed  for  demonstration  purposes 
only,  should  employ  verification  and  validation  fully  at  all  stages  of  development. 

3.3  Knowledge-Based  Systems 

As  evidenced  from  existing  CA  programs,  Knowledge  Based  Systems  (KBS)  is  the  most  important  AlP  area  in 
terms  of  the  potential  of  use  within  the  CA  program.  Therefore  an  investigation  of  knowledge-based  systems  is 
performed  for  the  CA  program.  Expert  Systems  (ES)  is  another  name  used  for  KBS  in  a  narrower  sense,  where  in 
ES  the  knowledge  base  is  formed  using  domain  expert  knowledge  whereas  in  KBS  knowledge  may  be  obtained 
from  other  sources  [4].  Most  current  applications  of  knowledge  processing  combine  knowledge-based  systems 
technology  with  other  conventional  methods  to  produce  an  overall  solution  to  a  particular  problem. 

Many  functionalities  of  the  Crew  Assistant  application  are  well  suited  to  realize  using  the  KBS  technology.  It  can 
be  said  that  the  Crew  Assistant  is  primarily  a  KBS  application. 

The  KBS  technology  offers  advantages  in  several  dimensions  in  the  Crew  Assistant  application: 

In  terms  of  functionality,  KBS  technology  may  be  employed  in  all  application  areas  chosen  for  the  Crew 
Assistant.  KBS  are  very  reliable  when  compared  with  a  human.  Therefore  KBS  technology  will  increase  the 
reliability  of  the  aircraft-crew  system.  KBS  offers  reasonable  performance  for  real-time  applications.  KBS 
technology  offers  modular  design  and  development.  KBS  technology  is  integrable  with  other  technologies. 
Integrability  should  be  another  important  criterion  in  selecting  KBS  tools  to  be  employed  within  the  Crew 
Assistant  program.  Application  development  based  on  KBS  technology  is  well  suited  for  employing  different 
engineering  methodologies  including  the  classical  waterfall  model  and  the  prototyping  model.  There  are  many 
tools  to  support  KBS  technology,  and  human  expertise  is  not  scarce. 

Therefore,  it  can  be  concluded  that  KBS  technology  satisfies  all  the  criteria  set  for  the  evaluation  of  the  generic 
AIP  areas  and,  similar  to  the  existing  CA  programs,  it  is  expected  that  it  will  find  several  uses  in  this  CA  program 
as  well. 

On  the  other  hand,  it  should  be  noted  that  some  aspects  of  KBS  technology,  i.e.  those  areas  that  are  the 
potentially  weak  points  of  KBS  technology  for  the  CA  program,  should  be  evaluated  critically.  Knowledge 
acquisition  and  assuring  timeliness  in  real  time  are  among  these  aspects.  Performance  should  be  an  important 
criterion  in  selecting  KBS  tools  to  be  employed  within  the  Crew  Assistant  program. 

3.4  Distributed  Artificial  Intelligence 

The  subject  Distributed  Artificial  Intelligence  (DAI)  addresses  distributed  problem  solving  by  multiple 
cooperative  processing  elements.  It  is  concerned  with  issues  of  coordination  among  concurrent  processes  at  the 
problem-solving  and  representation  levels  [5].  It  differs  from  the  more  general  area  of  distributed  processing 
because  it  is  concerned  with  distributing  control  as  well  as  data  and  can  involve  extensive  cooperation  between 
entities.  Distributed  processing  systems  address  the  problem  of  coordinating  a  network  of  computing  agents  to 
carry  out  a  set  of  separate  and  mostly  independent  tasks,  as  opposed  to  DAI.  Distributed  processing  focuses  on 
now  bits  of  data  can  be  physically  moved  among  machines.  So  distributed  processing  or  programming  such  as 
client-server  are  out  of  the  scope  of  DAI. 

Two  categories  of  DAI  research  exist:  parallel  artificial  intelligence  and  distributed  problem  solving  (DPS). 
Parallel  A1  refers  to  a  fine-grained  efficiency-oriented  approach,  also  referred  to  as  connectionism.  Neural 
networks  are  an  example.  DPS  refers  to  coarse-grained  (task-level)  problem  decomposition  resulting  in  a  number 
of  expert  or  knowledge-based  systems,  generally  called  agents.  Each  of  these  entities  include  or  exhibit  some 
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intelligence,  whereas  parallel  A1  systems  consist  of  entities  that  are  relatively  simple  in  construction  and  do  not 
exhibit  any  intelligence,  but  the  overall  system  exhibits  some  intelligence  based  on  patterns  of  data  processing  of 
these  fine  entities  (e.g.  neurons  in  neural  networks)  [6]. 

The  Crew  Assistant  application  is  primarily  categorized  as  a  system  of  cooperating  expert  systems  for  computer 
supported  cooperative  work.  Crew  Assistant  is  a  complex  application.  The  development  of  a  Crew  Assistant  will 
already  result  in  a  complex  system.  DPS  has  a  number  of  features  to  manage  this  complexity.  Therefore;  it  is 
recommended  to  apply  DPS  technology  in  the  Crew  Assistant  for  the  following  reasons: 

•  modularity,  reduced  complexity  and  reduction  life 

•  concurrent  and  incremental  development, 

•  inherent  distribution  of  the  application  (functional),  integration  of  heterogeneous  systems, 

•  reliability, 

•  easy  mapping  of  task  domains  on  agents, 

•  considers  the  limited  availability  of  resources, ' 

•  data  abstraction, 

•  handling  of  bounded  response  times  and  reasoning,  and 

•  real-time  behavioral  characteristics. 

From  a  functional  point  of  view,  relating  DPS  to  Crew  Assistant  Architecture  as  discussed  in  this  section  shows 
that  blackboard  systems  and  multi-agent  systems  are  relatively  made-to-measure  technologies  for  Crew  Assistant. 
These  technologies  can  be  applied  to  both  element  and  system  level. 

DPS  technology  will  increase  reliability  (and  flight  safety)  of  Crew  Assistant  if  non-determinism  is  kept  to  an 
absolute  minimum.  Total  flight  safety  is  only  guaranteed  if  the  Crew  Assistant's  task  is  to  support  the  crew,  the. 
crew  will  always  be  in  command  as  final  authority,  and  delegated  autonomous  operation  may  only  be  considered 
for  simple,  routinely  tasks  that  ensures  deterministic  and  predictable  agent  behavior. 

In  order  to  achieve  acceptable  real  time  performance  in  DPS,  the  tendency  is  to  let  a  multi-agent  system  form  the 
backbone  architecture  of  a  Crew  Assistant  and  to  apply  blackboard  system  technology  to  local  problem  solving 
(within  an  agent). 

Decomposition  of  Crew  Assistant  by  task  domain  and  level  of  processing  will  form  the  basis  for  a  modular 
system  architecture  of  multiple  cooperating  agents.  It  allows  for  development  and  maintenance  in  a  structured 
manner  in  order  to  be  able  to  anticipate  to  the  ever  changing  operational  environment,  aircraft  systems  and 
military  demands. 

DPS  provides  rich  concepts  far  easy  integration  all  kinds  of  methods  and  techniques,  conventional  as  well  as 
advanced  information  processing. 

With  respect  to  an  engineering  methodology,  the  heterogeneous  aspect  of  DPS  technology,  system  engineering 
should  be  a  migration  of  conventional,  object-oriented  and  knowledge-based  system  engineering  methodologies 
with  additional  agent-specific  and  user  interaction  design  features.  It  should  allow  for  incremental  development 
(prototyping). 

The  potency  of  DPS  technology,  blackboard  systems  as  well  as  multi-agent  systems,  is  recognized  in  the 
aerospace  community.  A  rich  set  of  tools  is  already  available.  Prototype  and  operation  real-time  applications 

Because  of  the  nice  features  of  DPS  and  the  progress  in  research,  tools,  applications  and  multi-processor 
technology  that  is  currently  being  made,  it  can  be  concluded  that  DPS  sy.stems  ba.scd  on  multi-processor 
technology  will  play  a  dominant  role  in  next  generation  advanced  information  processing  technologies. 

On  the  other  hand,  the  overall  complexity  of  applying  DPS  to  Crew  Assistant  should  not  be  underestimated.  In 
order  to  control  complexity  as  well  as  to  achieve  the  required  performance,  decomposition,  distribution  and. 
cooperation  strategies  should  not  be  too  flexible.  In  that  sense,  the  following  measures  can  be  taken  for  CA 
development; 

•  develop  the  CA  incrementally  (range  of  prototypes)  to  increase  functionality  and  performance  step  by  step 

•  provide  a  good  development  environment  (an  advanced  DPS  toolkit  is  required) 

•  apply  decomposition  on  basis  of  a  formally  prescribed  task  hierarchy 
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•  a  priori  known  distribution  of  tasks  among  agents 

•  avoid  conflicts  between  agents 

•  design  a  fixed  community-like  organization  of  agents  with  strict  rules  of  behavior  based  on  identified  task 
domains  (functionally  decomposed  agents  such  as  mission  planning,  situation  assessment,  etc.). 

•  reduce  non-determinism, 

•  make  use  of  next  generation  on-board  hardware  resources  based  on  multi-processor  technology 

•  do  not  include  explicit  redundancy  as  a  main  objective  in  the  CA  in  order  to  manage  complexity  and  to  focus 
mainly  on  functional  problem  solving.  Nevertheless,  a  secondary  design  goal  should  be  to  meet  future 
reliability  requirements  and  should  be  taken  into  account. 

•  apply  resource  management. 

In  conclusion,  it  is  recommended  to  apply  DPS  technology  in  Crew  Assistant  and  let  it  be  a  driving  technology 
for  the  overall  Crew  Assistant  architecture. 

3.5  Learning  Systems 

Most  KBS  are  hand-built  systems  without  any  learning  capability.  Whenever  necessary,  they  are  modified 
manually.  Although  such  systems  appear  to  be  simple  there  are  inherent  difficulties  associated  with  them  [7],  [8]. 

•  Difficulty  of  assuring  completeness  and  correctness  of  knowledge  bases.  It  is  generally  assumed  that  the 
knowledge  base  of  hand-built  KBS  is  complete  and  correct.  However,  for  most  real  world  tasks,  achieving 
completeness  and  correctness  are  extremely  difficult,  if  not  impossible. 

•  Increased  time  complexity.  Making  a  knowledge  base  as  complete  and  as  correct  as  possible  may  entail 
writing  thousands  of  interacting,  possibly  recursive,  rules.  Using  such  rule  sets  may  be  very  demanding  in  real 
time  applications. 

•  Difficulty  of  modifying  knowledge  bases.  As  interactions  increase  in  a  rule  set,  it  becomes  difficult  to 
predict  all  of  the  changes  resulting  from  modifying  a  single  rule. 

Therefore,  a  mechanism  of  automating  knowledge  introduction  to  the  KBS  is  necessary.  It  is  possible,  in 
principle,  to  achieve  this  by  making  the  system  capable  of  learning. 

With  respect  to  inductive  learning,  if  noisy  data  is  present  it  is  highly  probable  that  the  knowledge  base  will  not 
be  consistent  and  complete.  The  time  complexity  of  inductive  learning  algorithms  does  not  allow  them  to  be  used 
in  real  time  applications.  Also,  the  requirement  of  verification  and  validation  requires  them  to  be  used  off  line. 
Inductive  learning  may  be  used  to  generate  or  augment  the  knowledge  bases  of  the  KBS  to  be  used  in  the  CA. 

Genetic  algorithms  (GA),  on  the  other  hand  are  used  for  .  combinatorial  and  parameter  optimization.  Although 
they  have  the  ability  to  locate  the  global  optimum,  depending  on  the  control  parameters,  the  possibility  of  being 
trapped  in  a  local  minimum  exists.  GA  do  not  have  a  reliable,  bounded  convergence  time  for  the  global  optimum. 
However,  they  have  the  graceful  degradation  property,  they  always  present  solutions  that  improve  over  time.  GA 
allow  modularity  but  they  are  not  scaleable.  There  is  not  an  established  methodology  for  designing  a  GA 
application. 

Other  than  learning,  artificial  neural  networks  (ANN)  are  also  used  for  classification,  and  function 
approximation,  i.e.,  time  series  forecasting,  control  etc.  Current  melhodologies  ol  training  neural  networks  do  not 
allow  them  to  be  used  on-line.  For  this  reason,  training  should  be  carried  out  offline.  Once  trained,  an  ANN  can 
perform  prediction  in  real-time.  However,  after  each  mission;  data  gathered  during  mission  can  be  used  to 
improve  the  ANN  used  in  the  CA,  thus  allowing  it  to  adapt  to  changing  situations,  enemy  vehicles,  etc.  ANN  are 
at  least  as  reliable  as  other  classification  systems,  if  not  more. 

To  summarize,  learning  can  be  used  in  the  CA  in  two  stages: 

•  In  the  initial  construction  of  the  rule  based  knowledge  bases  such  as  in  self-detense  and  mission  planning 
application  areas,  and 

•  In  the  maintenance  of  the  above  mentioned  knowledge  bases. 

For  the  initial  construction,  inductive  learning  or  genetics  based  learning  will  be  more  appropriate,  as  these 
methods  produce  symbolic  output.  However,  during  the  maintenance  phase,  all  of  the  three  learning  methods  can 
be  used.  Although,  ANN  are  marginally  better  than  the  other  two  methods,  re-extracting  symbolic  knowledge 
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from  the  ANN  structure  after  beaming  is  a  costly  process. 

It  is  also  expected  that  ANN  will  be  used  for  classification  and  recognition  tasks  based  on  low  level  data,  such 
processing  environmental  data  or  systems/malfunctions  data  that  may  also  amount  to  sensor  fusion. 

3.6  Planning 

In  a  CA,  one  fundamental  AIP  problem  is  to  deal  with  a  set  of  variables  belonging  to  the  real  world  domain  and 
with  a  set  of  possible  actions,  in  order  to  determine  the  sequence  of  actions  allowing  to  reach  the  current  goal. 
This  is  a  typical  planning  problem  (9)  because  the  system  has  to  generate  a  sequence  of  actions  that  will  achieve 
given  goals  in  a  domain  complex  enough  that  the  appropriateness  and  consequences  of  the  actions  depend  upon 
the  world  states  in  which  they  are  to  be  executed,  in  particular,  the  planning  system  must  keep  track  of  and  reason 
about  differing  world  states  at  different  point  in  time.  This  feature  distinguishes  the  planing  problem  from  similar 
problems  such  as  '  scheduling.  In  fact,  in  scheduling,  the  problem  is  to  assign  resources  in  order  to  carry  out  a 
plan  without  requiring  that  the  system  reason  about  how  the  world  changes  as  scheduled  events  occur. 

Planning  is  still  a  research  area.  There  is  not  a  single  operational  planner  that  can  solve  all  the  problems  of 
planning  (especially  in  real  time)  and  there  are  no  commercial  tools  available  for  planning. 

The  applications  realized  in  literature  seem  to  be  on  quite  easy  problems,  with  real  constraints  not  being  very 
strict.  Although  the  modem  planners  seem  to  be  able  to  cope  with  most  of  the  problems  of  planning  (non 
linearity,  real  time  etc.)  as  they  are  all  based  on  the  search  on  the  state  space,  there  is  a  need  for  paying  attention. 
In  the  CA,  planning  can  provide  significant  improvement  in  the  quality  of  help  that  the  system  can  offer  to  the 
pilots,  providing  a  new  plan  as  the  modification  of  the  current  plan  as  required  by  the  changes  in  the  external 
situation. 

Due  to  the  difficulties  and  the  technical  risks  inherent  to  these  technologies  it  is  recommended  to  pay  great 
attention  to  the  planner  architecture  and  to  develop  the  CA  in  a  scenario  of  realistic  dimensions.  This  is  to  verify 
that  the  system  can  really  cope  with  the  real  time  problem. 


3.7  Model-Based  Reasoning 

Model  based  reasoning  is  a  sub-field  of  artificial  intelligence  oriented  to  device  representation.  The  word 
"model"  means  "a  decomposition  of  a  real-world  .device  into  components  which  captures  the  structure  of  the 
device  and  its  components,  and  the  way  the  components'  actions  give  rise  to  the  device's  actions  as  a  whole"  [10]. 
The  model  based  approach,  compared  with  the  traditional  artificial  intelligence  approach,  is  a  step  forward  in 
many  ways.  Traditional  artificial  intelligence  approaches  usually  rely  on  heuristic  knowledge  elicited  from  a 
human  expert.  This  allows  the  realization  of  systems  that  exhibit  a  very  good  agreement  with  the  experts.  On  the 
other  side,  there  are  strong  limitations  in  terms  of  performances,  flexibility,  explanation  capability.  The  model 
based  approach  allows  to  overcome  such  limitations,  because  model  based  systems  are  largely  device¬ 
independent,  more  easy-to  maintain,  built  with  re-usable  component  models,  and  o  their  explanation  capabilities 
are  built-in.  Moreover;  they  overcome  the  difficulties  of  dealing  with  new  devices,  on  which  there  is  ml  expertise 
available,  and  shows  a  graceful  degradation  of  performances  at  the  boundaries  of  the  domain  knowledge,  where 
traditional  systems  usually  simply  stop  working. 

The  model  based  approach  is  suitable  for  applications  where  it  is  necessary  to  represent  complex  devices  whose 
behavior  must  be  simulated  and  monitored  (for  instance,  with  diagnostic  purposes).  With  such  an  approach,  it  is 
easier  to  cope  with  the  complexity  of  the  Crew  Assistant  application.  It  may  be  difficult  to  attain  the  required 
real-time  performance,  unless  other  types  of  knowledge  (associational,  procedural,  etc.)  is  incorporated  in  the 
system.  However,  such  an  integration  could  raise  difficulties,  in  maintaining  the  overall  consistency  of  the 
knowledge  embedded  in  the  system.  Moreover,  with  the  present  state  of  the  art,  it  is  not  possible  to  guarantee  the 
reliability  of  such  an  approach.  Therefore,  the  model  base  reasoning  should  be  considered  only  as  a  supporting 
approach. 

On  the  other  hand,  a  model  based  representation  is  clear,  easy  to  maintain  and  to  extend.  It  is  suitable  for  an  easy 
implementation  of  graphical  development  tools  and  reusable  component  libraries.  The  system  can  be 
incrementally  developed,  making  it  possible  to  check  and  to  understand  the  needs  and  problems  better  at  each 
step. 

Currently,  there  are  no  powerful  commercial  tools  available.  Nevertheless,  the  technology  is  mature  enough. 
Some  companies  seem  to  have  achieved  very  good  results.  It  is.  expected  that  they  will  commercialize  their  tools 
soon. 
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3.8  Case-Based  Reasoning 

Computer  systems  that  solve  new  problems  by  analogy  with  old  ones  are  often  called  Case-Based  Reasoning 
(CBR)  systems  [11].  A  CBR  system  draws  its  power  from  a  large  case  library,  rather  than  from  a  set  of  first 
principles  alone.  Essential  to  the  success  of  a  case-based  system  is  the  development  of  a  rich-set  of  indexing 
mechanisms  by  which  cases  are  built  and  retrieved.  The  case-based  paradigm  can  be  used  for  building  intelligent 
agents  that  use  heuristic  knowledge,  first  principles  as  well  as  special-case  knowledge  from  previous  experiences. 

Case-based  reasoning  is  a  cognitively  plausible  model  of  reasoning  and  a  method  for  building  intelligent  systems. 
It  is  grounded  in  .commonsense  premises  and  observations  of  human  cognition  and  has  applicability  to  a  variety 
of  reasoning  tasks,  providing  for  each  a  means  of  attaining  increased  efficiency  and  better  performance.  Case- 
based  reasoning  integrates  problem  solving,  understanding,  learning  and  memory  into  one  framework.  . 

The  CA  application  is  primarily  categorized  as  a  system  of  cooperating  expert  systems  for  computer  supported 
cooperative  work.  The  development  of  a  CA  will  result  in  a  complex  system.  For  the  implementation  of  one  or 
more  of  these  cooperating  expert  systems  CBR  might  be  a  reasonable  approach. 

3.9  Object-Oriented  Databases 

The  Object-Oriented  Databases  technology  was  developed  over  the  last  5  years  as  a  mix  of  the  programming 
methodologies  based  on  the  object-oriented  approach  and  the  more  traditional  database  techniques  aimed  to 
allow  an  efficient  and  reliable  management  of  persistent  data  [12]. 

By  introducing  not  only  the  persistency  but  also  other  key  features  (such  as  secondary  store  management, 
concurrency  control,  recovery  capabilities,  access  facilities  etc.)  into  a  paradigm  targeted  on  improving  software 
reliability,  reusability,  modularity  and  adherence  to  the  reality,  the  OODB  have  done  a  major  step  toward  the 
unification  of  the  programming  and  data  management  technologies. 

Since  this  achievement  can  be  exploited  at  its  best  when  the  system  to  be  developed  must  deal  with  very  complex 
data  (where  complexity  is  meant  both  in  terms  of  structure  and  interactions),  the  Crew  Assistant  project  seems 
particularly  suitable  to  take  advantage  of  its  benefits,  as  this  will  result  in  an  efficient  and  productive 
development  of  reliable,  reusable  and  highly  modular  software. 

Object-oriented  database  technology  is  in  accordance  with  all  the  software  engineering  requirements  (modularity, 
performance,  integrability,  etc.) 
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1.  INTRODUCTION 

Pour  les  missiles  de  croisifere  et  les  avions  k  long 
rayon  d’ action,  des  donndes  gdographiques  ont  6t6 
utilisdes  tr^s  tot  pour  des  fonctions  de  navigation 
comme  le  recalage  de  navigation  et  la  navigation 
tr6s  basse  altitude.  Pour  le  recalage  de  navigation 
deux  types  de  donndes  ont  6t6  utilisdes  :  des 
donndes  de  relief  (DEM  :  Digital  Elevation  Model) 
ou  des  donndes  topographiques  (landmarks  ou 
amers)  ;  pour  la  navigation  trfes  basse  altitude  : 
essentiellement  des  donndes  de  relief.  Le 
ddveloppement  des  satellites  d’ observation  ^  partir 
des  anndes  70  a  permis  de  constituer  assez 
rapidement  des  bases  de  donndes  de  relief 
importantes  ;  la  constitution  de  MNT  (Moddle 
Numdrique  de  Terrain)  a  partir  d’un  couple 
stdrdoscopique  est  largement  automatisable  et 
ndcessite  done  peu  d’ intervention  de  I’opdrateur  ; 
d’ autre  part  on  pent  penser  que  sur  des  surfaces 
assez  dtendues  le  relief  est  une  information  assez 
stable  dans  le  temps  et  qui  pent  done  etre  prdparde 
assez  longtemps  a  I’avance  contrairement  aux 
donndes  planimdtriques  (cultural  features)  de 
nature  plus  dphdmdre.  Ceci  a  donnd  naissance  aux 
donndes  DTED  (Digital  Terrain  Elevation  Data) 
qui  se  prdsentent  sous  la  forme  de  donndes  mailldes 
correspondant  a  des  pavds  de  3  ”  x  3”  d’arc  (soit 
une  maille  d’a  peu  prds  60  m  x  90  m  a  la  latitude 
de  45°).  Les  donndes  planimdtriques  du  type 
DEAD  (Digital  Features  Analysis  Data)  se  sont 
ddveloppdes  de  manidre  plus  indgale  que  les 
donndes  DTED  et  leur  qualitd  est  probablement 
plus  variable  car  leur  saisie  ne  peut  etre 
compldtement  automatisde  et  comporte  done  une 
part  d’interprdtation  tant  dans  la  sdlection  des 
dldments  que  dans  le  tracd  retenu  (gdndralisation). 
D’autre  part  le  DEAD  avait  au  ddpart  une 
couverture  limitde,  principalement  le  thdatre 
Centre-Europe.  Or  les  thdatres  d’opdrations  sur 
lesquels  ont  dtd  utilisds  ces  demidres  anndes  les 
avions  d’arme,  sont  extdrieurs  a  cette  zone 
(Falklands,  Bosnie,  Irak,  Burundi, ....). 

Dans  un  premier  temps,  principalement  destindes  a 
I’aide  a  la  navigation  radar,  ces  donndes 
privildgiaient  les  dldments  topographiques 
susceptibles  de  produire  des  donndes  relatives  aux 


dchos  forts  (e’est  ainsi  que  seuls  les  tron9ons 
d’axes  routiers  sur  talus  pouvaient  etre  sdlectionnds 
car  seuls  donnant  des  dchos  forts).  Puis  devant  le 
ddveloppement  des  systdmes  de  commandement  la 
vocation  «  dchos  forts  »  s’est  dtendue  pour  donner 
une  reprdsentation  topographique  compldte  de  la 
zone.  Les  fichiers  a  vocation  militaire  se  sont  alors 
rapprochds  des  donndes  du  domaine  civil. 

Le  ddveloppement  des  systdmes  d’ information 
gdographiques  civils  ou  militaires  (SIG/GIS),  des 
systdmes  d’ information  et  de  commandement 
militaires  (S1C/C2I/C3I),  des  simulations  et  des 
jeux  de  guerre  a  poussd  a  la  constitution  de  bases 
de  donndes  nouvelles  plus  prdcises,  de  couvertures 
toujours  plus  dtendues.  Ces  bases  de  donndes 
peuvent  etre  utilisdes  pour  les  fonctions  de  recalage 
de  navigation  sur  de  grandes  dtendues  comme  pour 
le  missile  de  croisidre  APACHE  sous  maitrise 
d’ oeuvre  MATRA-DEEENSE  et  dont  THOMSON- 
CSF  rdalise  prdcisdment  le  Radar  de  Recalage  et 
de  Ddtection.  Mais  ces  bases  de  donndes  peuvent 
aussi,  comme  on  va  le  montrer,  etre  utilisdes  pour 
I’Aide  a  r Identification  d’Objectifs  dans  les 
missions  Air-Sol.  En  effet,  meme  si  pour  ces 
missions,  le  pilote  dispose  gdndralement  d’une  vue 
capteur  sur  laquelle  il  peut  ddsigner  la  cible  par  ses 
propres  moyens,  il  est  intdressant  d’automatiser  au 
mieux  les  phases  de  reconnaissance  et 
d’ identification  pour  que  le  pilote  n’ait  qu’a 
confinner  la  ddsignation  qui  lui  est  alors  proposde 
par  le  systdme  et  se  concentrer  sur  le  choix  du 
point  d’ impact. 

Dans  le  but  de  montrer  comment  peut  se  prdsenter 
cette  aide,  la  prdsentation  aborde  alors  les  points 
suivants  : 

-  quelles  donndes  gdographiques  et  sous 
quelles  formes  peuvent  faciliter  la  tache  du  pilote  ? 

-  ces  donndes  existent-elles  (avec  un 
panorama  sur  les  donndes  en  projet)  ? 

-  exemples  d’ utilisation  de  ces  donndes 
pour  r  Aide  k  1’ Identification. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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2.  AIDE  A  L’lDENTIFICATION  AIR- 
SOL  ET  DONNEES  GEOGRAPHIQUES 

Quel  peut-etre  Tapport  des  sources  de  donndes 
gdographiques  dans  le  cadre  des  missions  air-sol 
et,  plus  particuli5rement  en  ce  qui  conceme  I’aide 
k  r identification  ?  La  notion  d’ identification  air- 
sol  est  considdrde  ici  au  sens  large  du  terme,  k 
savoir  comme  ensemble  de  phases  de  ddtcction,  de 
localisation  ou  d’ identification  proprement  dite  de 
la  cible  ou  de  Tamer  considdr6.  La  cible  peut  elle- 
meme  entrer  dans  deux  categories  distinctes.  La 
premibre  est  celle  des  cibles  fixes,  par  exemple  les 
superstructures  (routes,  ponts,  batiments)  ;  la 
deuxibme  conceme  les  cibles  en  mouvement  et  les 
cibles  ddpla^ables 

Dans  un  cas  comme  dans  Tautre,  T identification 
s’appuie  sur  Tutilisation  de  donnbes  de  reference 
eiaborees  en  preparation  de  mission,  et  qui  se 
rapportent  suivant  les  cas  h  la  cible  elle-meme  ou  h 
son  environneraent.  Ces  donnbes  pemiettent  une 
analyse  en  cours  de  mission  de  T  image  foumie  par 
un  capteur  optronique  embarque  afin  de  fourair  des 
indications  sur  une  zone  de  presence  probable  de  la 
cible,  puis  sur  Tidentification  de  la  cible  lorsqu’elle 
est  detectee  et  localisee. 

L’apport  potentiel  des  sources  de  donnees 
geographiques  se  situe  au  niveau  de  la  creation  de 
donnees  de  reference.  Considerons  tout  d’abord  le 
cas  des  donnees  « classiques »,  de  type  carte 
geographique  ou  photographic  satellitaire  (SPOT). 
I.,a  phase  de  recherche  de  la  zone  de  presence 
probable  de  la  cible  peut  s’appuyer  sur  ce  type  de 
donnees  qui  renseignent  sur  la  presence  et  la 
position  des  superstructures  ^  rechercher  dans 
T image  courante,  et  qui  permettent  de  delimiter  la 
zone  d’interet.  Cette  etape  est  menee  k  bien  k  un 
niveau  global  et  conceme  Tenvironnement  de  la 
cible.  Une  grande  precision  de  localisation  n’est 
pas  ndeessaire. 

Les  limitations  des  donndes  geographiques 
« classiques »  apparaissent  dans  les  phases  de 
localisation  precise  et  d’ identification  de  la  cible 
elle-meme.  Les  deux  categories  de  cibles  presentees 
plus  haut  ouvrent  sur  deux  types  de  besoins 
nouveaux. 

Les  cibles  fixes  (superstructures,  batiments,  ....) 
sont  la  plupart  du  temps  prdsentes  dans  des 
donnees  geographiques  classiques.  La  limitation 
vient  dans  ce  cas  de  la  precision  ou  du  type  de 
representation. 

Prenons  Texemple  d’une  route,  qu’elle  soit  la  cible 
elle-meme  ou  un  element  servant  ^  la  localisation 
precise  d’unc  cible.  Une  carte  gbograpbique,  du  fait 
de  la  representation  schematique  adoptee,  ne 


permettra  pas  de  la  localiser  precisement,  tant 
qu’aucune  donnbe  rdelle  sur  sa  largeur  ni  d’ailleurs 
de  son  trace  precis  ne  sont  connues. 

D’autre  part,  la  localisation  precise  et 
Tidentification  des  cibles  fixes  rendent  nbeessaires 
la  disponibilite  d’ informations  de  precision 
mbtrique  qui  ne  peuvent  pas  etre  foumies  dans  les 
sources  classiques  (peut-etre  cependant  avec  des 
satellites  de  la  classe  IffiLIOS  ou  de  la  nouvelle 
generation  commercial  qui  voit  le  jour  aux  Etats- 
Unis). 

Le  cas  des  cibles  mobiles  et  des  cibles  dbplaqables 
est  different,  puisqu’aucune  information 
concemant  leur  position  precise  n’est  connue  en 
preparation  de  mission.  L.es  sources  de  donnbes 
classiques  qui  se  limitent  k  des  informations  de 
type  geometrique  ne  sont  done  pas  exploitables,  en 
dehors  de  la  determination  d’une  zone  de 
recherche.  Seules  des  informations  de  contexte 
pourraient  eventuellement  guider  les  phases  de 
detection  et  d’ identification  de  ce  type  de  cible. 

Ce  constat  pourrait  paraitre  assez  pessimiste  en 
mettant  en  evidence  notamment  les  points 
suivants  : 

-  la  relative  pauvretb  des  donnbes  dont  on  peut 
disposer  en  Preparation  de  Mission  au  vu  des 
resolutions  trbs  grandes  obtenues  avec  les  cambras 
de  bord  ;  ceci  est  particulibrement  vrai  pour  des 
theatres  extbrieurs  mal  cartographies  ; 

-  T inadaptation  d’une  source  de  donnbes  d’bchelle 
gbographique  fixe  alors  que  sur  T image  avion  il 
peut  y  avoir  des  rapports  d’bchelle  de  1  h  10  entre 
le  haut  et  le  bas  d’ image  ; 

-  la  schbmatisation  des  objets  des  bases  de  donnbes 
geographiques  qui  les  rend  difficilement 
reconnaissables  sur  les  vues  obliques  en  basse 
altitude ; 

Pourtant,  lors  des  operations  abriennes  de  la 
rbeente  Guerre  du  Golfe,  des  statistiques 
intbressantes  ont  btb  btablies  sur  la  probabilitb  pour 
le  pilote  d’identifier  sur  une  image  sa  cible  k  coup 
sur  en  ne  disposant  comme  rbfbrence  que  de  la 
carte  topographique  de  la  zone  et  des  coordonnbes 
de  la  cible  ;  d’aprbs  certaines  analyses  cede 
probabilitb  s’blbverait,  dans  de  nombreux  cas,  k 
moins  de  50%  k  la  premibre  passe.  L’ utilisation 
d’une  image  type  SPOT  convenablement  mise  en 
perspective,  une  des  techniques  prbsentbes  ici, 
semble  avoir  augmentb  de  manibre  considerable  les 
chances  de  tir  rbussi  au  premier  rendez-vous.  II 
n’existait  que  peu  de  fichiers  gbographiques 
vccteurs  sur  TIrak  aussi  les  images  SPOT  ont-clles 
btb  intensbment  utilisbes  ;  il  est  certain  que  la 
disponibilite  de  fichiers  vecteurs  aurait  pu  aussi 
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conduire  k  un  bon  pourcentage  de  tirs  r^ussis  dfes 
la  premibre  approche. 

Les  images  suivantes  illustrent  I’int^ret,  mais  aussi 
les  limites  de  1’ utilisation  des  images  SPOT  pour 
Taide  k  T identification  par  le  pilote. 

Dans  un  premier  cas  on  compare  une  vue 
a^roportde  (en  haul)  avec  une  vue  SPOT  raise  en 
perspective  (en  bas)  pour  paraitre  k  peu  pr6s  sous 
les  memes  conditions  de  prise  de  vue.  On  constate 
que  la  corr61ation  visuelle  entre  les  deux  images  est 
facile  (d’autant  que  Tangle  de  site  61ev6  de  la  prise 
de  vue  minimise  les  distorsions). 


permettre  de  passer  rapidement  en  petit  champ  sur 
Tobjectif  qu’il  aura  localise  facilement  et  alors  de 
proc6der  k  T identification. 

Dans  le  second  cas,  la  scbne  est  plus  complexe  et  il 
y  a  moins  d’amers  pr6dominants.  L’image  du  haut 
est  un  ex  trait  d’une  image  a6roport6e  ;  celle  du  bas 
est  obtenue  k  partir  de  la  r^troprojection  d’une 
image  SPOT.  La  scbne  est  h  plus  basse  altitude  que 
la  pr6c6dente. 


Des  differences  apparaissent  au  niveau  des 
batiments  dont  T6ievation  n’est  pas  prise  en 
compte  dans  la  raise  en  perspective  SPOT  et  dans 
la  difference  d’ occupation  des  quais  (les  images 
n’ayant  pas  ete  prises  k  la  meme  date). 

Neanmoins  si  le  pilote  dispose  de  la  vue  basse 
calcuiee  4  partir  d’une  image  SPOT  teiechargee  et 
des  conditions  inertielles  courantes,  cela  doit  lui 


Les  contrastes  n’etant  pas  les  memes  entre  les 
images,  la  correlation  automatique  est  plus 
difficile;  contrairement  k  la  vue  precedente,  il  y  a 
plus  de  possibilites  d’appariements  entre  les 
elements  rectilignes  ce  qui  complique  la  validation 
rapide  de  la  correlation  automatique  proposee.  Il 
est  alors  preferable  d’utiliser  conune  reference  des 
fichiers  d’objets  geographiques  comme  on  va  le 
voir. 
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3.  DONNEES  GEOGRAPHIQUES  POUR 
L’AIDE  A  L’IDENTIFICATION  AIR-SOL 

Seront  disponibles  ^  terme  pour  etre  utilis6es  dans 
des  missions  d’attaques  d’objectifs  au  sol  et  pour 
remplacer  ou  compldter  les  donndes  DLMS,  les 
trois  classes  de  donndes  suivantes  dont  des 
exemples  sont  pr6sent6s : 

-  donndes  hectomdtriques  (DCW;  Digital  Chart  of 
the  World  ;  couverture  mondiale  ;  dchelle  adaptde 
aux  cartes  au  1/1  000  000  ou  moins) ; 

-  donndes  ddcamdtriques  (VMAP  :  Vector  Map  ; 
couverture  mondiale  ;  souvent  prdsentd  comme  le 
successeur  du  DLMS/DFAD  ;  dchelle  adaptde  aux 
cartes  au  1/100  000) ; 

-  donndes  mdtriques  (type  BD  Topo  de  I’lnstitut 
Gdographique  National  en  France)  ;  prdcision  de 
classe  mdtrique  ;  la  constitution  de  telles  bases  de 
donndes  est  ondreuse  et  la  couverture  mondiale  ne 
se  fera  sans  doute  que  trbs  lentement ;  par  contre  la 
croissance  du  marchd  des  images  satellitaires  et  la 
mise  sur  le  marchd  de  systbmes  de  restitution 
photogrammdtrique  k  faible  cout  permettront 
probablement  de  rdaliser  des  fichiers  sur  des  petites 
zones  dans  des  conditions  opdrationnelles 
raisonnables  de  cout  et  de  ddlai. 

Les  deux  images  ci-contre  illustrent  ces  deux 
demiers  types  de  donndes  sur  la  meme  rdgion.  Le 
point  de  vue  choisi  pour  la  mise  en  perspective  des 
images,  le  meme  pour  les  deux  vues,  est  une 
distance  capteur  /centre  image  de  20  000  m,  une 
altitude  de  5  000  m  et  un  champ  carrd  de  4°  x  4°. 
Sur  chacune  des  images  seuls  les  objets 
appartenant  aux  quatre  thbmes  :  cours  d’eau, 
r^seau  routier,  rdseau  ferrd,  limites  de  vdg6tation 
sont  reprdsentds  k  des  fins  de  comparaison. 

Avant  d’ analyser  plus  en  ddtail  I’intdret  reprdsentd 
par  chacun  de  ces  trois  types  de  donndes,  on  peut 
tirer  de  leur  comparaison  les  informations 
suivantes: 

-  les  donndes  DCW  ne  sont  gdndralement  pas 
assez  riches  (sauf  dans  le  fond  d’ image  ^  faible 
site)  pour  faciliter  la  reconnaissance  ; 

-  les  donndes  type  VMAP  permettent  un  bon 
quadrillage  de  la  zone  ;  en  bas  d’ image  la 
reprdsentation  est  toutefois  un  peu  schdmatique  ; 

-  les  donndes  du  type  BD  Topo  peu  vent  paraitre 
trop  riches  pour  ce  type  d’dchelle  ;  il  serait  en  effet 
trbs  difficile  de  faire  de  la  corrdlation  automatique 
image  et  carte  projetde  avec  cette  densitd 
d’616ments  ;  cependant  au  moins  dans  la  partie 
basse  de  T  image  la  prdcision  gdomdtrique  est  bien 
celle  exigde  par  le  champ  et  la  resolution  de 
r  image  ;  seuls  certains  dldments  doivent  done  etre 


seiectionnds  pour  entrer  dans  des  programmes  de 
recalage  automatique. 


Type  VMAP 


Type  BD  Topo. 

L’intdret  potentiel  de  fichiers  de  donndes 
gdographiques  6tant  reconnu  encore  faut-il  pour  en 
tirer  un  bon  parti  respecter  certaines  conditions 
d’emploi. 
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Comme  on  I’a  d6j&  soulignd  deux  probl6mes 
majeurs  se  posent : 

-  les  regies  de  saisie  des  6I6ments  qui  figurent  dans 
les  fichiers  gdographiques  ne  prennent  pas  en 
compte  la  visde  oblique  et  cherchent  plutot  ^  avoir 
une  reprdsentation  homog^ne  en  visde  verticale  ; 
ceci  complique  beaucoup  I’utilisation  de  tels 
fichiers  en  vue  trbs  oblique  puisque  I’dchelle  entre 
le  haul  et  le  bas  d’image  n’est  pas  du  tout  la  meme 
(le  rapport  d’dchelle  pour  une  hauteur  de  vol  de 
600  m,  une  portde  de  15  000  m  et  un  champ  de  4° 
est  supdrieur  h  10) ;  les  dldments  seront  tr6s  denses 
dans  le  fond  d’image  et  trbs  clairsemds  dans  le  bas 
d’image ; 

-  les  contraintes  de  representation  des  fichiers 
gdographiques  vecteurs  ne  sont  pas 
particulibrement  orientdes  vers  la  lisibilitd 
cartographique  ;  ainsi  la  voirie  pourra  etre 
reprdsentde  par  les  axes  des  voies  plutot  que  par  les 
bords  qui  sont  pourtant  plus  visibles  que  I’axe  sur 
I’image.  D’autre  part  il  n’y  a  gdudralement  pas  de 
contrainte  sur  rdpaisseur  des  traits  ou  des  objets 
qu’ils  ddlimitent.  Les  parties  masqudes  peuvent 
aussi  n’etre  pas  totalement  respectdes. 

Malgrd  ces  ddfauts  les  donndes  gdographiques 
vecteurs  peuvent  etre  une  source  prdcieuse 
d’ informations  dans  I’aide  h  1’ identification  Air- 
Sol. 

Pour  le  montrer  on  a  considdrd  plusieurs  sources  de 
donndes  sur  la  mdme  zone  et  aprds  les  avoir 
compardes  en  vue  oblique,  on  les  a  compard  en  vue 
verticale  ici.. 

Les  donndes  prdsentdes  (k  1’ exception  du  DCW) 
sont  issues  d’un  jeu  d’essais  mis  gracieusement  k 
disposition  d’industriels  h  fin  d’ expertise  par 
rinstitut  Gdographique  National  Franqais. 

Les  sources  de  donndes  sont  sur  la  meme  zone  et 
reprdsentatives  des  futurs  produits  VMAP  et  autres 
produits  k  plus  grande  dchelle. 

La  meme  zone  est  reprdsentde  en  vue  verticale  h  la 
meme  rdsolution  (sauf  le  DCW)  pour  juger  des 
densitds  respectives. 

Les  sources  de  donndes  sont  les  suivantes  : 

-  DCW,  Digital  Chart  of  the  World 

-  BD  Carto  de  I’IGN,  dchelle  approximative  du 
1/50  000  (reprdsentative  du  VMAP) 

-  BD  Topo  de  I’IGN,  dchelle  approximative  du 
1/15  000. 

Ces  deux  demidres  BD  ont  naturellement  pour 
vocation  de  couvrir  le  territoire  franqais. 
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Au  vu  de  ces  diffdrents  fichiers,  il  est  tentant  de 
rdaliser  des  images  pr6dites  qui  soient  un  hybride 
de  ces  diffdrentes  sources  de  donndes  (dans  la 
mesure  ou  ces  diffdrents  fichiers  sont  disponibles) ; 
dans  le  fond  utilisation  du  DCW  ou  VMAP  et  dans 
la  partie  basse  de  T  image  utilisation  de  VMAP  ou 
type  BD  Topo.  Un  exemple  d’une  combinaison  des 
donndes  type  VMAP  et  type  BD  Topo  est  montrd 
sur  la  figure  ci-dessous  dans  les  mSmes  conditions 
de  prise  de  vue  que  pour  les  trois  vues  prdcddentes. 
La  densitd  des  dldments  repr6sent6s  est  plus 
homogfene  sur  I’ensemble  de  Timage.  Les  raccords 
ne  sont  pas  parfaits  car  la  prdcision  n’est  pas 
identique  pour  les  diffdrents  fichiers.  Cela  ouvre 
pourtant  la  porte  h  la  realisation  de  compositions 
originales  dans  lesquelles  la  densitd  sur  1’ image  est 
k  peu  pres  constante. 


preparation  de  mission  pour  sdlectionner  suivant 
I’axe  de  vol  la  bonne  densite  d’ elements  en 
fonction  de  la  profondeur.  Ce  point,  comme  il  sera 
montre  dans  le  chapitre  suivant,  est  crucial  pour 
une  bonne  rdussite  des  algorithmes  de  recalage 
automatique. 


La  source  de  donnees  gdographiques  qui  apparait 
la  plus  appropriee  tant  au  point  de  vue  de  la 
couverture,  de  la  precision  requise  (du  moins  pour 
I’Aide  k  ITdentification)  que  de  la  disponibilite 
semble  bien  etre  la  source  VMAP.  Un  probieme 
risque  pourtant  de  se  poser  avec  ce  type  de  fichiers 
(comme  il  s’est  d’ailleurs  pose  avec  les  donnees 
DFAD/DLMS)  :  la  variation  de  qualite  avec  les 
zones  ;  les  rbgles  de  fabrication  permettent  en  effet 
difficilement  de  s’assurer  que  la  qualite  est 
homogfene  en  couverture  et  en  precision  sur  toute  la 
zone  couverte. 

11  est  possible  aussi  d’envisager  pour  ces  fichiers 
des  modes  de  representation  qui  soient  plus  adaptes 
4  la  reconnaissance  aerienne  qu’ils  ne  le  sont 
maintenant:  par  exemple  pour  des  voies  de  largeur 
non  negligeable,  preciser  le  trace  des  bords  plutot 
que  I’axe.  Des  efforts  sont  aussi  k  faire  en 
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4.  EXEMPLE  D’UTILISATION  DE 
DONNEES  GEOGRAPHIQUES  DANS 
L’AIDE  A  L’IDENTIFICATION  AIR-SOL 

Un  des  objectifs  de  I’aide  k  1’ identification  est  de 
d6signer  automatiquement  an  pilote  la  cible  dans 
I’image  lots  du  premier  passage  de  I’avion.  Pour 
contribuer  ^  cette  mission  THOMSON-CSF  a 
d6velopp6  un  algorithme  utilisant  les  donn6es 
g6ographiques. 

Quand  P  avion  atteint  la  position  estim6e  pour 
laquelle  la  cible  est  dans  le  champ  de  vision 
Palgorithme  capture  une  image  et  en  extrait  les 
616ments  caractdristiques.  Ces  616ments  doivent 
etre  comparables  aux  donnfes  g6ographiques 
disponibles.  Dans  le  cas  d’attaque  de  sites 
comprenant  des  superstructures,  P  utilisation  de 
segments  de  droite  pr6sente  plusieurs  avantages  : 

-  tout  d’abord,  ils  sont  directement  en 
addquation  avec  les  donndes  du  modble  qui  sont 
classiquement  repr6sent6es  sous  forme  de  vecteurs, 

-  ensuite,  il  existe  plusieurs  techniques 
d’ extraction  de  segments  qui  pr6sentent  de  bonne 
probability  de  dytection  et  une  faible  fausse  alarme; 

-  enfin  une  bonne  pr6sence  de  ces 
yiyments  dans  toute  P  image. 

L’ identification  de  la  cible  repose  sur  la  mise  en 
correspondance  entre  les  segments  extraits  de 
Pimage  et  ceux  d’un  modble  tel  que  pr6sent6  dans 
le  paragraphe  pryc6dent.  En  fonction  des 
parambtres  de  la  mission  (incertitudes  sur  les 
parambtres  de  vol,  distance  d’ acquisition,  champ 
du  capteur, ...)  la  projection  du  modble  k  partir  des 
donnbes  inertielles  de  navigation  prbsente 
principalement  des  erreurs  de  translation;  les 
distorsions  sont  faibles  et  peuvent  etre  nbgligbes  en 
premibre  approximation.  On  pent  envisager  deux 


approches  pour  retrouver  la  position  exacte  d’un 
modble  projetb  dans  une  image  ; 

1.  La  premibre  regroupe  des  mbthodes 
‘descendantes  ’  de  Pensemble  des  solutions  vers 
Pimage.  Ce  sont  des  approches  du  type  corrblation 
oil  Pon  teste  toutes  les  positions  possibles  en 
associant  k  chacune  un  cout  de  superposition.  La 
position  correspondant  au  cout  le  plus  faible  foumit 
la  position  du  modble.  Ces  mbthodes  peuvent  se 
combiner  avec  des  approches  pyramidales  ou  Pon 
choisit  diffbrentes  possibilitbs  de  recalage  h  de 
faibles  prbcisions,  solutions  que  Pon  affine  et 
distingue  k  de  meilleures  rbsolutions. 

Ces  mbthodes  demandent  la  mise  au  point  de 
fonctions  de  cout  discriminantes  qui  sont  souvent 
couteuses  en  temps  de  calcul.  De  plus  beaucoup  des 
solutions  testbes  correspondent  4  des  recalages 
image/modble  impossibles  et  il  faut  possbder  le 
rbsultat  de  la  fonction  de  cout  pour  les  bliminer. 


2.  L’ autre  catbgorie,  comprend  les  mbthodes 
‘montantes’  de  Pimage  vers  Pensemble  des 
solutions.  On  pense  ici  aux  mbthodes  par 
accumulation  oil  la  solution  se  dbtache 
progressivement  en  accumulant  des  informations 
locales.  Une  information  locale  correspond  ici  h 
une  hypothbse  de  dbplacement  superposant  un 
segment  modble  avec  un  segment  image.  En 
reprbsentant  toutes  ces  transformations  dans  un 
espace  approprib  on  obtient  par  effet  de  vote  la 
solution  qui  recouvre  le  plus  d’blbments  du  modble 
sur  Pimage. 

Dans  le  cas  oil  la  transformation  h  identifier  est 
une  translation,  Pespace  d’accumulation  est  de 
dimension  deux  suivant  les  axes  image  et  forme  ce 
que  Pon  appelle  couramment  une  nappe 
d’accumulation. 

La  figure  suivante  prbsente  un  cas  typique  de 
nappe  d’accumulation  vue  en  3D. 
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Op6rationellement  la  s61ection  du  pic  le  plus  haul 
n’est  pas  toujours  suffisante  pour  determiner  la 
bonne  solution  avec  la  meilleure  precision.  C’est 
pourquoi  la  detection  du  bon  pic  est  associde  ^  un 
critbre  de  qualitd  dependant  localement  de  la 
nappe  d’ accumulation  et  des  segments  apparids. 

Pour  r  application  considdrde,  THOMSON-CSF  a 
retenu  une  mdthode  accumulative  dont  un 
organigramme  gdneral  est  donnd  figure  suivante. 


Organigramme  de  la  mdthode  accumulative. 


Le  nombre  et  la  qualitd  des  hypotheses  accumuldes 
sont  des  facteurs  fondamentaux  pour  le  bon 
fonctionnement  de  ce  type  de  mdthode.  En  effet 
toute  hypothdse  erronde  bruite  la  nappe 
d’ accumulation  et  fragilise  la  recherche  d’une 
solution  globale.  C’est  pourquoi  on  utilise 
classiquement  des  critdres  de  comparaison 
gdomdtrique  entre  les  segments  image  et  moddle 
pour  former  les  hypotheses  locales  les  plus 
probables  avant  de  les  accumuler. 

L’ utilisation  de  donndes  gdographiques  permet  en 
preparation  de  mission  de  constituer  des  moddles 
dont  les  caractdristiques  peuvent  amdliorer 
r identification.  II  est  toujours  difficile  d’dtablir  des 
rdgles  de  selection  exhaustives.  Cependant  on  pent 
retenir  quelques  rdgles  simples. 


II  parait  en  particulier  intdressant  de  sdlectionner 
des  elements  longs,  car  la  probabilitd  qu’un  tel 
segment  extrait  dans  1’ image  soit  du  bruit  est 
faible.  II  est  dgalement  important  de  disposer  de 
segments  dans  diffdrentes  classes  d’orientation.  On 
peut  aussi  s’intdresser  h  la  repartition  des  dldraents 
dans  la  scdne  en  s’assurant  d’une  certaine 
homogdnditd  ou  au  contraire  en  favorisant  des 
structures  caractdristiques  (noeud  routier,  ...). 

Enfin,  si  Ton  a  une  connaissance  suffisamment 
precise  de  la  configuration  d’attaque  (cap 
d’arrivde,  distance,  altitude,  ...),  on  peut 
sdlectionner  les  dldments  en  fonction  de  la 
resolution  du  pixel  dans  1’ image.  Par  exemple  pour 
rarridre  plan  on  ne  retiendrait  que  les  dldments 
aux  dimensions  les  plus  importantes  (par  exemple 
les  berges  comme  limites  d’un  fleuve).  A  1’ oppose 
pour  le  premier  plan  on  retiendrait  des  dldments  de 
dimensions  plus  faibles  ddfinis  avec  une  bonne 
resolution. 

Du  point  de  vue  opdrationnel  ces  critdres  de 
selection  (gdomdtriques,  topologiques,  ...)  peuvent 
etre  automatisds. 

Un  dernier  apport  des  nouvelles  donndes 
gdographiques  serait  d’associer  aux  primitives  des 
attributs.  On  disposerait  ainsi  de  critdres  de 
selection  suppldmentaires  comprenant  par  exemple 
la  visibilitd  (gdomdtrique,  radiomdtrique)  ou  leur 
aspect  dans  I’image.  Par  exemple  dans  le  cas  des 
segments,  la  connaissance  du  sens  du  contraste 
quand  elle  est  disponible  et  pertinente,  dans  les  cas 
de  transition  eau/terre  par  exemple,  peut  dviter  des 
erreurs  de  recalage. 


Les  figures  suivantes  prdsentent  un  exemple  de 
recalage  pour  I’aide  k  1’ identification  d’objectif  sur 
une  zone  portuaire. 

La  premidre  image  prdsente  le  moddle  embarqud 
projetd  h  partir  des  conditions  inertielles.  Ce 
moddle  a  dtd  constitud  en  prdparation  de  mission  i 
partir  de  fichiers  gdographiques  en  utilisant  des 
heuristiques  de  sdlection. 

Les  traits  rouges  correspondent  aux  segments 
ex  traits  sur  I’image,  les  segments  superposds  en 
vert  reprdsentent  les  dldments  du  moddle  projetds  i 
partir  des  donndes  inertielles. 

La  seconde  image  prdsente  le  rdsultat  du  recalage 
en  translation  du  moddle  sur  I’image. 


Module  initial  et  segments  extraits. 


Module  recal6  et  segments  extraits 


Aprds  cede  dtape,  le  pilote  pent  passer  aux  phases 
suivantes  de  1’ identification. 


5.  CONCLUSION 


L’ information  gdographique  dont  il  a  6t6 
principalement  parl6  dans  cet  exposd  est  de  nature 
gdomdtrique  ou  sdmantique.  On  a  vu  son  intdret  et 
son  utilisation  pour  I’aide  k  1’ identification 
automatique  d’objectifs.  On  a  dgalement  prdsentd 
des  approches  spdcifiques  pour  la  constitution  des 
modules  embarquds  en  particulier  par  I’utilisation 
conjointe  de  fichiers  gdographiques  avec  des 
resolutions  diffdrentes  ou  encore  par  la  raise  en 
place  de  entires  autoraatiques  de  selection. 

Peu  a  ete  dit  sur  les  proprietes  de  rayonnement 
eiectromagnetique  des  objets  qui  sont  pourtant  si 
sensibles  au  niveau  des  capteurs  infrarouge  ou 


autres.  Cette  information  n’apparait  pratiquement 
pas  dans  les  nouveaux  fichiers  de  donndes 
geographiques.  Pourtant,  on  a  vu  qu’^  I’origine  ces 
proprietes  etaient  h  la  base  merae  de  la  leur 
constitution.  Bien  que  delicate  ^  maitriser  en 
fonction  des  conditions  operationnelles, 
r  utilisation  de  ces  proprietes  aiderait  le  processus 
d’aide  ^  1’ identification. 

En  conclusion  de  cet  expose  on  pourrait  souhaiter 
que  des  informations  de  rayonnement 
eiectromagnetiques  retrouvent  leur  place  dans  ces 
fichiers  comme  ne  1’ exclue  d’ailleurs  pas  la  norme 
mais  comme  ne  le  montre  pas  de  manibre 
manifeste  la  pratique. 


22-10 


Remerciements 

THOMSON-CSF  remercie  le  STTE  qui  a  finance 
r^tude  IDAS  (Identification  Air  Sol)  au  titre  de 
laquelle  les  travaux  pr6sent6s  ont  6t6  en  partie 
d6velopp6s. 

THOMSON-CSF  remercie  dgalement  la 
CEGN/DGA  pour  la  mise  ^  disposition  des  donndes 
VMAP,  ainsi  que  ITGN  pour  la  mise  k  disposition 
des  donndes  BD  Topo  et  BD  Carto. 


23-1 


Conception  des  systemes  de  gestion  de  mission  : 
approches  technique  et  methodologique 

P.Sassus,  F.Bonhoure,  T.L.Mariton 

SEXTANT  Avionique,  Aerodrome  de  Villacoublay,  BP59 
78141  Velizy,  France 


1.  Introduction 

Forte  de  sa  competence  dans  le  domaine  de  la 
conduite  du  vol  et  plus  particulierement  de  la 
gestion  du  vol  notamment  sur  les  programmes 
majeurs  d’avions  d’armes  Mirage  2000  et 
Rafale,  SEXTANT  Avionique  s’interesse 
depuis  plusieurs  annees  au  developpement  de 
systemes  de  gestion  de  mission  permettant  une 
prise  en  compte  temps  reel  de  revolution  du 
contexte  operationnel  (environnement  tactique, 
meteorologique,  avion). 

Dans  le  but  de  defmir  une  function  embarquee 
adaptee,  des  expertises  ont  ete  recueillies  aupres 
des  operationnels  de  I'Armee  de  lAir  et  de 
I'Aeronavale  qui  ont  permis  de  determiner  son 
role,  son  domaine  d'emploi,  son  niveau  de 
performances  (en  terme  de  temps  de 
reponse,...),  d’interactivite  homme-systeme,  et 
les  strategies  de  reconfiguration  adaptees. 

Toutefois,  compte  tenu  de  la  variete  des 
theatres  d'operation,  des  missions,  des  porteurs 
possibles  et  de  leurs  equipements,  cette 
definition  ne  doit  pas  etre  consideree  comme 
unique  ou  figee.  C'est  pourquoi  les  choix 
d'architecture  et  de  methodologie  de 
developpement  effectues  doivent  favoriser 
I'adaptabilite  de  la  function  a  I'evolutivite  des 
exigences. 

La  presente  publication  decrit  ainsi  I'approche 
technique  et  methodologique  adoptee  pour  le 
developpement  de  tels  systemes  et  se  compose 
de  quatre  parties.  Le  chapitre  2  presente  la 
fonction  Gestion  de  Mission  telle  que  definie 
actuellement.  Les  chapitres  3  et  4  decrivent 


respectivement  les  principes  d'architecture 
retenus  et  la  methodologie  de  developpement. 
Le  chapitre  5  presente  I'environnement  de 
simulation  et  d' evaluation  pilotee  de  la  fonction. 
Les  travaux  relates  ici  sont  soutenus  par  les 
services  etatiques  fran9ais  (STTE)  dans  le  cadre 
de  marches  d'etude. 

2.  Definition  de  la  Fonction  Gestion  de 
Mission 

2.1.  Cahier  des  charges 

2.1.1.  Caracteristiques  des  missions 
considerees 

Les  recueils  d’ expertise  ont  ete  axes  sur  les 
principales  missions  envisagees  actuellement 
(attaque  air/sol,  assaut  mer  et  defense  aerienne) 
dans  I'optique  d’ identifier  tres  precisement,  en 
fonction  des  phases  de  la  mission,  les  strategies 
de  reconfiguration  habituellement  adoptees 
pour  prendre  en  compte  revolution  moyen/long 
terme  du  contexte  (tactique,  meteorologique)  ou 
des  parametres  internes  avion  (temps,  petrole, 
trajectoire). 

Suivant  le  type  de  mission  considere,  les 
strategies  peuvent  differer  :  la  preservation  du 
potentiel  ou  I'accomplissement  de  la  mission 
seront  privilegies.  Dans  le  cadre  des  missions 
de  plus  en  plus  frequentes  que  I'Armee  de  I'Air 
et  I'Aeronavale  sont  amenees  a  effectuer  au 
profit  d'operations  de  maintien  de  la  paix 
(Bosnie-Herzegovine  par  exemple),  le  cout 
(humain,  financier,  politique)  de  la  perte  d'un 
appareil  et  de  son  equipage  est  juge  prohibitif 
au  regard  de  I'importance  de  la  mission.  En  cas 
d'incident,  I'objectif  de  la  replanification  sera 
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alors  d'assurer  la  sauvegarde  de  I'appareil,  en 
general  au  prix  de  I'echec  de  la  mission.  Dans 
d'autres  cas,  la  reussite  de  la  mission  sera 
eonsideree  comme  primordiale  (hypothese  d'un 
eonflit  en  Centre  Europe),  fusse  au  prix  de  la 
perte  d'un  ou  plusieurs  avions. 

A  Tissue  des  recueils  d'expertise,  il  est  apparu 
une  meilleure  adequation  entre  Taide  apportee 
par  la  fonetion  avee  les  missions  de  type 
attaque  Air/Sol  et  Assaut  Mer  qu'avec  la 
mission  Air/ Air. 

En  effet,  etant  donne  les  contraintes 
extremement  serrees  de  Thoraire  sur  Tobjeetif 
des  missions  d'assaut,  le  respect  du  plan  de  vol 
(trajet,  passage  des  lignes,  phase  d'attaque  ...)  et 
du  timing,  determines  lors  de  la  preparation  de 
mission,  sont  prioritaires. 

En  regie  generale,  la  trajectoire  en  zone  amie  se 
fait  en  altitude  et  a  vitesse  moyenne  pour 
minimiser  la  consommation  tandis  qu'en  zone 
ennemie,  on  privilegie  le  moindre  risque  en 
choisissant  de  voler  a  tres  basse  altitude  le  plus 
vite  possible  en  respectant  la  situation  tactique. 
Dans  la  phase  retour,  la  surveillance  du 
carburant  devient  plus  importante. 

Les  reconfigurations  d'itineraire  eh  vol, 
destinees  a  un  avion  seul  ou  au  dispositif  entier, 
visent  a  satisfaire  Tensemble  des  parametres  de 
la  mission. 

Dans  le  cadre  de  la  mission  Air/Air,  les  besoins 
en  matiere  de  respect  du  plan  de  vol,  tant  du 
point  de  vue  trajectoire  que  du  point  de  vue 
timing  sont  bien  moins  importants,  la  gestion 
du  carburant  conservant ,  elle,  toute  son  acuite. 

2.1.2.  Contexte  operationnel 

Contexte  tactique : 

La  situation  tactique  est  en  general  bien  connue 
au  moment  de  la  preparation  de  mission,  surtout 
dans  les  conflits  recents  ou  une  phase  de  crise 
permet  Taccumulation  de  renseignements  avant 
Tordre  d'execution  de  la  mission. 

La  connaissance  des  menaces  Air/Air  lors  de  la 
preparation  de  mission  n'influe  pas  sur  le  trace 


de  Titineraire  (position  et  dotation  inconnues  au 
moment  de  la  mission)  mais  elle  determine, 
pour  une  part,  les  caracteristiques  du  dispositif. 
En  fonetion  de  la  letalite  connue  de  la  menace 
Sol/Air,  des  capacites  des  Contre  Mesures 
Electroniques  d'autoprotection  et  de 
Timportance  accordee  a  la  reussite  de  la 
mission,  Titineraire  devra  contoumer 
imperativement  la  zone  de  menace  ou  accepter 
de  la  traverser  partiellement  en  tachant  de 
limiter  la  vulnerabilite  de  I'appareil. 

Contexte  meteo : 

Les  avions  modernes  etant  dotes  de  capacites 
IMC  (Instrument  Meteorological  Conditions), 
Timpact  de  la  meteo  est  globalement  assez 
faible  sur  Torganisation  et  le  deroulement  de  la 
mission.  Le  pilotage  en  IMC  necessite  pourtant 
une  attention  plus  soutenue  de  la  part  du  pilote 
(phenomenes  de  desorientation,  risque 
d'abordage). 

Dans  les  conflits  de  type  Bosnie-Herzegovine 
ou  la  minimisation  des  dommages  collateraux 
est  une  preoccupation  constante,  les  regies 
d'engagement  imposent  une  identification  de  la 
cible.  Dans  le  cas  de  trop  mauvaises  conditions 
(visibilite  inferieure  a  la  portee  de  Tarme),  la 
mission  est  done  annulee. 

Pour  Tatterrissage,  des  conditions  meteo  peu 
favorables  conduisent  le  pilote  a  augmenter  ses 
marges  de  carburant  pour  etre  capable 
d'eventuellement  operer  un  deroutement. 

2.1.3.  Hypotheses  systemes  armement 
capteurs 

Le  besoin  operationnel  pour  des  fonctions  de 
type  "Elaboration  De  Trajectoires",  semble  fort 
dans  le  cadre  de  missions  d'attaque  Air/Sol  avee 
penetration  en  basse  altitude.  Le  scenario  retenu 
est  done  celui  d'une  attaque  d'un  objectif  unique 
par  tir  d'AGL.  Destinees  a  des  missions  de 
TArmee  de  TAir  comme  de  TAeronavale,  la 
fonetion  s'adresse  a  une  patrouille  de  4  avions 
dotes  de  capacite  IMC  (Instrument 
Meteorological  Condition)  et  d'un  systeme 
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MIDS  (Multifunction  Information  Distribution 
System). 

2.2.  Definition  de  la  fonction 

2.2.1.  Principes  d'assistance 

La  fonction  "Elaboration  De  Trajectoires" 
repose  sur  une  fonctionnalite  centrale 
d’ elaboration  de  trajectoires  qui  doit  permettre 
des  reconfigurations  3D/4D  du  plan  de  vol  ou 
de  la  trajectoire  avion  compatibles  des 
contraintes  globales  de  la  mission  (timing, 
petrole,  trajectographie,...). 

Sur  cette  base,  trois  types  d'assistances  sont 
proposees: 

-  detection  d'evenements  perturbants, 

-  propositions  de  reconfigurations  d'itineraires 
associees  aux  detections  d'evenements 

-  assistances  specifiques  : 

.  evaluation  d'itineraires  specifiques  (retour, 
ravitaillement), 

.  modifications  des  contraintes  du  plan  de 
vol  courant, 

.  evaluation  d'un  plan  de  vol  construit  par  le 
pilote, 

.  changement  du  Dest, 

.  evaluation  de  I'accessibilite  des  terrains  de 
recueils 

.  fenetre  de  consultation 

2.2. 1 .1  .Detection  d'evenements  perturbants 

Les  detections  d'evenements  sont  issues  des 
traitements  de  surveillance  du  contexte 
(acquisition  d'evenements  externes,  surveillance 
du  respect  du  timing  et  des  capacites  en  petrole, 
surveillance  de  la  faisabilite  de  reconfigurations 
par  anticipation  telle  que  rejointe  ou  regulation 
en  vitesse  et  plus  generalement  de  la  faisabilite 
de  proposition  de  reconfiguration).  Elies  ont 
pour  but  d'informer  le  pilote  de  la  degradation 
des  conditions  de  realisation  de  la  mission 
compte  tenu  de  I'itineraire  en  cours.  Elies  sont 
filtrees  en  fonction  de  leurs  importances  et  de  la 
phase  de  mission  en  cours. 


Pour  memoire  les  evenements  suivants  peuvent 
etre  emis  : 

.  non  respect  d'une  contrainte  temporelle 
.  non  respect  de  la  reserve  petrole  sur  le 
terrain 

.  apparition  de  menaces  nouvelles  court  ou 
long  terme 

.  meteo  defavorable  sur  zone 

.  panne  conduisant  a  la  remise  en  cause  de  la 

mission 

2.2. 1 .2.  Propositions  de  reconfiguration 

Une  proposition  de  reconfiguration  est  toujours 
associee  a  une  detection  d'evenement  ou  a  un 
ecart  de  trajectoire  (spatial  ou  temporel) 
effectue  par  le  pilote.  Elle  represente  la  solution 
du  systeme  face  a  I'evenement  qui  est  a  I'origine 
du  probleme.  Elle  est  proposee  au  pilote  a  la 
suite  de  sa  detection  et  met  en  oeuvre  I'expertise 
pilote  en  matiere  de  reconfiguration  d'itineraire. 
Les  evenements  donnant  lieu  a  une  proposition 
automatique  de  reconfiguration  sont  les 
suivants  : 

.  non  respect  d'une  contrainte  temporelle 
.  non  respect  de  la  reserve  petrole  sur  le 
terrain 

.  apparition  de  menaces  nouvelles  court  ou 
long  terme. 

Ces  propositions  sont  entretenues  afm  de  tenir 
compte  de  I'avancement  de  I'avion.  L'entretien 
s'arrete  soit  si  le  pilote  valide  la  proposition  qui 
lui  est  faite  soit  si  les  conditions  ne  permettent 
plus  au  systeme  de  proposer  une  solution 
(retard  excessif  par  exemple). 

Le  traitement  des  autres  evenements  (meteo 
defavorable  et  panne  conduisant  a  la  remise  en 
cause  de  la  mission)  est  laisse  a  I'initiative  du 
pilote  qui  peut  alors  utiliser  les  assistances 
specifiques. 

2.2.1 .3.  Assistances  specifiques 

En  fonction  du  type  d'assistance  demandee,  le 
renseignement  de  parametres  peut  etre 
necessaires.  Cela  implique  une  interaction  avec 
le  pilote  qui  peut  influer  sur  la  dynamique  des 
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traitements  a  mettre  en  oeuvre.  Les  differents 
cas  sent  decrits  ci-apres. 

Evaluation  d'un  itineraire  de  retour 
Sur  demande  pilote,  le  systeme  calcule  un 
itineraire  de  retour  sur  le  terrain  de  recueil  le 
plus  proehe.  Le  pilote  n'a  pas  de  parametres  a 
renseigner.  L'itineraire  propose  est  entretenu 
tant  que  le  pilote  ne  I'a  pas  valide  ou  n'a  pas 
annule  sa  demande. 

Evaluation  d'un  itineraire  de  ravitaillement 
Le  systeme  calcule  un  itineraire  de  rejointe  a  un 
pattern  de  ravitaillement  defmi  en  preparation 
de  mission.  Aucun  parametre  n'est  necessaire. 
L'itineraire  propose  est  entretenu  jusqu'a  la 
validation  par  le  pilote  ou  desactivation  de  cette 
assistance  au  ravitaillement. 

Modifications  des  contraintes  du  plan  de  vol 
courant 

Le  pilote  modifie  certaines  contraintes  du  plan 
de  vol  (route,  timing,  reserve  de  petrole).  Apres 
modification,  un  nouvel  itineraire  est  calcule. 
Les  parametres  necessaires  sont  les  contraintes 
modifiees  et  leurs  nouvelles  valeurs.  L'itineraire 
4D  obtenu  est  presente  et  considere 
automatiquement  comme  le  nouvel  itineraire 
courant. 

Evaluation  d’un  plan  de  vol  construit  par  le 
pilote 

Le  pilote  pent  definir  manuellement  un  plan  de 
vol  en  designant  ou  en  creant  successivement 
des  buts  de  navigation.  A  chaque  nouvelle 
designation  d'un  but,  l'itineraire  rejoignant  le 
dernier  but  designe  est  calcule  a  partir  de  la 
localisation  definie  par  le  pilote  et  presente.  Le 
processus  de  construction  se  termine  soit  par  la 
validation  de  l'itineraire  construit  soit  par  son 
annulation. 

Changement  du  but  Best 

Un  itineraire  de  rejointe  est  calcule  de  telle 
maniere  que  le  point  de  rejointe  de  l'itineraire 
courant  se  trouve  sur  le  segment  precedent  le 
but  designe  par  le  pilote  comme  etant  son 
prochain  but  de  destination. 


Evaluation  de  I’accessibilite  des  terrains  de 
recueils 

Le  traitement  d'evaluation  de  I'accessibilite  des 
terrains  de  recueils  en  petrole  est  active  sur 
demande  pilote  et  reactualise  en  permanence  les 
informations  calculees  pour  tenir  compte  de 
I'avancement  de  I'avion  et  de  sa  consummation 
de  petrole.  Le  pilote  n'a  aucun  parametre  a 
entrer.  Ce  traitement  est  desactive  par  le  pilote. 

Fenetre  de  consultation 
Le  traitement  "fenetre  de  consultation"  est 
active  par  le  pilote  lorsqu'il  designe  un  but.  Les 
informations  presentees  dans  le  file  de 
consultation  sont  reactualisees  pour  tenir 
compte  de  I'avancement  de  I'avion  et  de  sa 
consummation  de  petrole  tant  que  I'alidade  se 
trouve  sur  le  but.  Le  pilote  n'a  aucun  parametre 
a  renseigner. 

2.2.2.  Traitements  de  conduite  du  vol 

L'expression  du  besoin  operationnel  se 
traduisant  pour  I'essentiel,  par  I'entretien  d'une 
trajectoire  garantissant  le  suivi  de  l'itineraire 
nominal  de  la  mission  et  le  respect  des 
contraintes  associees,  la  fonction  Elaboration  de 
Trajectoires  propose  un  certain  nombre  de 
fonctionnalites  de  generation  d'itineraires.  Un 
ensemble  de  modules  basiques  de  generation  du 
profil  de  vol  (horizontal,  vertical)  et  d'habillage 
en  temps  et  en  petrole  assure  I'elaboration  des 
trajectoires  de  suivi  du  plan  de  vol  et  servent  de 
support  a  la  mise  en  oeuvre  des  trajectoires  de 
reconfiguration. 

Ces  modules  basiques  sont : 

-  generateur  de  profil  horizontal : 

cette  fonctionnalite  a  en  charge  la  generation 
d'une  trace  sol  reliant  les  buts  du  plan  de  vol 
entre  eux  compte  tenu  des  contraintes  de  vol 
(route  imposee,  hippodrome,  contrainte  pour 
conduite  de  tir). 

-  generateur  de  profil  vertical  : 

cette  fonctionnalite  genere  un  profil  vertical 
pour  un  vol  a  palier  contraint  (montees  et 
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descentes  comprises),  a  palier  Economique  ou 
bien  en  mode  de  suivi  de  terrain  . 

-  generateur  de  trajectoires  d'evitement  de 
menaces  : 

les  trajectoires  generees  par  cette  fonctionnalite 
prennent  en  compte  la  situation  tactique  afin  de 
proposer  un  itineraire  contournant  les  zones 
menaqantes. 

-  habillage  temps  /  petrole  : 

ce  module  propose  des  consignes  de  vitesse 
tout  le  long  de  I'itineraire  compte  tenu  des 
contraintes  horaires  de  la  mission  et  permet  une 
gestion  des  marges  de  carburant  pour  la 
realisation  de  la  mission. 

3.  Une  architecture  logicielle  pour  les 
systemes  de  gestion  de  mission 

L'architecture  logicielle  presentee  a  ete  con9ue 
en  deux  phases  possedant  des  objectifs  de 
complexite  croissante.  Au  cours  de  la  premiere 
phase  d'etude  (phase  d'etude  de  concept), 
l'architecture  devait  permettre  essentiellement 
de  faire  cooperer  un  ensemble  de  fonctions  de 
conduite  du  vol.  L'objectif  etait  alors  d'etudier 
ces  interactions  grace  a  une  modelisation 
adaptee  de  ces  fonctions.  Au  cours  de  la 
seconde  phase  de  developpement  (phase 
d'optimisation),  l'architecture  devait  permettre 
de  supporter  les  modes  operatoires  d'une 
fonction  embarquee  et  les  contraintes  temps 
reel  associees.  Pour  les  deux  phases 
I'adaptabilite  de  la  fonction  a  guide  les  choix 
d'architecture. 

3.1.  Phase  d'etude  de  concept 

3.1.1.  Objectifs 

Au  cours  de  la  phase  d'etude  de  concept,  le 
probleme  pose  etait  de  faire  cooperer  des 
fonctions  de  conduite  du  vol  pour  fournir  au 
pilote  une  aide  multi-domaines  a  la  gestion  de 
la  mission.  Pour  chaque  type  de  probleme  qui 
peut  survenir  au  cours  de  la  mission,  la 


recherche  d'une  solution  passe  par  I'intervention 
de  plusieurs  de  ces  fonctions  qui  sont  a  la  fois 
concurrentes  dans  le  traitement  de  certains 
sous-problemes  et  complementaires  pour  la 
resolution  complete  d'un  probleme  dorme. 
Aucune  contrainte  n'etait  imposee  quant  aux 
temps  de  reponse  ou  quant  a  une  logique 
operationnelle  de  gestion  des  traitements.  A  ee 
stade,  le  systeme  d'aide  est  un  systeme  de 
resolution  de  problemes  dont  on  cherche  a 
etudier  les  mecanismes  de  raisonnement. 

3.1.2.  Architecture  tableau  noir 

Une  architecture  multi-agents  de  type  "tableau 
noir"  a  ete  choisie  pour  sa  capacite  a  integrer  les 
differents  domaines  d'expertise  impliques  dans 
la  gestion  de  la  mission.  Elle  comporte  trois 
composants  essentiels  :  un  ensemble  de  sources 
de  connaissance  (SC)  dans  des  domaines 
d'expertise  propres  (appelees  aussi  modules 
specialises),  le  module  de  controle  (ou 
superviseur)  coordonnant  le  travail  des  Sources 
de  Connaissance  et  le  tableau  noir  proprement 
dit  constituant  I'espaee  de  resolution  des 
problemes  (hypotheses,  solutions  partielles, 
solutions  completes). 


Figure  1  Architecture  a  base  de  tableau  noir 


Le  controle  gere  I'activation  des  sources  de 
connaissance  en  fonetion  du  probleme  a 
resoudre  et  I'avancement  de  la  resolution.  Les 
sources  de  eormaissance  trouvent  sur  le  tableau 
noir  les  donnees  du  probleme  et  les  elements  de 
solution  deja  elabores  par  d'autres  sources  de 
connaissance  et  y  deposent  leur  propre 
contribution. 
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Le  tableau  noir  contient  I'ensemble  des  objets 
representant  la  mission  courante  et 
I'environnement:  le  plan  de  vol  courant  et 
I'itineraire  4D  courant,  I'avion,  une  base  de 
donnees  de  terrains  et  de  buts,  les  menaces,  les 
donnees  necessaires  au  ravitaillement. 

Cette  architecture  permet  de  separer  clairement 
les  connaissances  qui  sont  propres  au  domaine 
(regroupees  dans  les  sources  de  connaissance) 
des  connaissances  de  controle  relatives  aux 
strategies  de  resolution  (regroupees  dans  le 
module  de  controle)  qui  permettent  de 
determiner  a  chaque  etape  de  la  resolution  du 
probleme  les  connaissances  du  domaine  a 
mettre  en  oeuvre  (et  done  la  ou  les  sources  de 
connaissances  a  activer). 

Dans  cette  architecture,  chaque  fonction  de 
conduite  du  vol  est  representee  par  un  module 
specialise.  Le  superviseur  selectionne  et 
applique  les  actions  de  reconfiguration  en 
fonction  du  probleme  a  trader,  identifie  les 
differentes  combinaisons  de  cooperations 
possibles  entre  modules  specialises  permettant 
de  realiser  ces  actions  et  met  en  oeuvre  la  plus 
adaptee. 

Pour  cette  phase  d'etude  de  concept,  le  controle 
mis  en  oeuvre  par  le  superviseur  a  ete 
volontairement  opportuniste.  II  est  base  sur  un 
cycle  en  cinq  etapes  ; 

-  1)  selection  d'actions  de  reconfiguration  pour 
le  probleme  a  trailer, 

-  2)  mise  en  oeuvre  de  ces  actions  par  les 
modules  specialises  via  un  mecanisme  d'appel 
d'offre  conduisant  a  I'elaboration  d'un  itineraire 
reconfigure, 

-  3)  evaluation  de  I'efficacite  de  I'itineraire 
obtenu  (principalement  satisfaction  des 
contraintes  portant  sur  la  mission)  et  du  risque 
qu'il  engendre, 

-  4)  si  des  contraintes  ne  sont  pas  satisfaites  ou 
le  risque  trop  important,  la  satisfaction  de  la 
contrainte  prioritaire  devient  le  nouveau 
probleme  a  trailer, 

-  5)  Retour  a  I'etape  1). 


Ce  fonctionnement  permet  une  modelisation 
tres  modulaire  des  connaissances 
operationnelles  ;  chaque  element  de 
connaissance  associant  un  probleme  a  trader 
(evenement  survenu  en  cours  de  mission, 
contrainte  non  satisfaite)  a  une  ou  plusieurs 
actions  de  reconfiguration  censees  resoudre  (ou 
contribuer  a  resoudre)  le  probleme  en  question. 
Une  representation  simple  et  lisible  de  ces 
connaissances  permet  la  mise  au  point  des 
strategies  de  resolution.  Par  ailleurs,  le 
mecanisme  d'appel  d'offre  permet  d'aj  outer  une 
nouvelle  source  de  connaissance  au  systeme  de 
fafon  totalement  transparente  pour  le  controle. 
En  effet,  celui-ci  ne  connad  les  SC  qu'a  travers 
les  reponses  qu'elles  produisent  suite  a  un  appel 
d'offre.  En  revanche,  le  fonctionnement 
opportuniste  choisi  ne  permet  pas  un  controle 
suffisamment  sur  de  I'enchainement  des  actions 
mises  en  oeuvre  et  par  voie  de  consequence  du 
nombre  de  cycles  de  raisonnement. 

Cette  premiere  architecture  a  permis  d'obtenir 
des  solutions  pertinentes  pour  les  differents 
types  d'imprevus  envisages.  Par  ailleurs,  elle  a 
permis  de  progresser  de  maniere  significative 
dans  la  structuration  des  connaissances 
operationnelles  necessaires  et  dans  la  definition 
du  role  des  modules  specialises  et  algorithmes 
associes.  Les  enseignements  tires  de  cette 
premiere  phase  sont  developpes  au  paragraphe 
suivant  au  regard  des  objectifs  de  la  seconde 
phase. 

3.2.  Phase  d' optimisation 

3.2.1.  Objectifs 

De  nouveaux  objectifs  ont  ete  fixes  pour  cette 
phase  d'optimisation.  II  s'agit  de  permettre  le 
fonctionnement  en  temps  reel  d'un  ensemble  de 
traitements  concurrents  actives  par  I'arrivee 
d'evenements  externes  ou  par  le  pilote.  La 
definition  de  ces  traitements  decoule  des 
specifications  de  la  fonction  (voir  plus  haut). 
On  y  retrouve  les  raisonnements  de 
reconfiguration  d'itineraires  etudies  dans  la 
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phase  d'etude  de  concept  qu'il  s'agit  desormais 
de  mettre  en  oeuvre  dans  un  contexte  temps  reel 
conformement  a  la  logique  operationnelle  de 
fonctionnement  de  la  fonction. 

3.2.2.  Enseignements  tires  de  la  phase 
precedente 

Les  principaux  enseignements  tires  de  la  phase 
precedente  en  matiere  de  choix  d'architecture 
sont  les  suivants  : 

1)  Les  modules  specialises  definis  au  cours  de 
la  phase  d'etude  de  concept  correspondaient  a 
des  fonctions  de  conduite  du  vol.  Cela  a  permis 
de  mettre  en  evidence  des  besoins  d'interactions 
entre  modules  specialises  :  tel  module 
specialise  a  besoin  d'utiliser  certains  traitements 
elementaires  faisant  partie  d'un  autre  module 
specialise.  Ce  type  d'interaction  directe  entre 
modules  specialises  denature  I'architecture  a 
base  de  tableau  noir  dans  laquelle  les  modules 
specialises  ne  sont  pas  censes  se  connaitre 
mutuellement.  II  est  done  souhaitable  de 
distinguer  les  traitements  utilisant  des 
connaissances  operationnelles  des  traitements 
elementaires  partageables  et  de  rendre  ces 
demiers  independants  des  modules  specialises. 


2)  La  mise  en  cooperation  des  modules 
specialises  se  faisant  par  reponse  a  appel 
d'offre,  I'introduction  d'un  nouveau  module 
specialise  ne  modifie  pas  le  controle 
garantissant  une  forte  evolutivite.  Toutefois,  on 
constate  que  les  reponses  aux  appels  d'offre  du 
superviseur  conduisent  tres  souvent  aux  memes 
schemas  de  cooperation  entre  modules 
specialises.  Ces  quelques  schemas  sont  en  fait 
toujours  les  memes  sequences  de  traitements 
elementaires  heberges  par  certains  modules 
specialises.  Compte  tenu  de  la  remarque  1),  ce 
type  de  cooperation  pourrait  avantageusement 
etre  deplace  vers  les  modules  specialises  qui 
assurerait  ainsi  un  controle  local  sur  les 
traitements  elementaires. 

3)  Enfin,  les  objectifs  de  cette  seconde  phase  en 
matiere  de  maitrise  des  temps  de  reponse,  ne 
permettent  pas  de  conserver  simplement  un 
controle  opportuniste. 

3.2.3.  Architecture  de  la  fonction  Gestion  de 
Mission 

La  conception  de  I'architecture  s'appuie  sur  une 
analyse  globale  des  traitements  (analyse 


itineraires  et  autres 

assistances  evenements 


Figure  2  Architecture  de  la  fonction  Gestion  de  Mission 
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statique  (entrees/sorties,  dependances  de 
donnees)  et  analyse  dynamique  (periodicite, 
condition  d'activation  et  de  terminaison, 
priorites,  qualite  requise))  et  profite  des 
enseignements  tires  de  la  phase  precedente. 

L'architecture  a  base  de  tableau  noir  est 
reconduite  mais  avec  une  structuration 
differente  des  modules  specialises  et  un 
controle  favorisant  la  maitrise  des  temps  de 
reponse  et  pouvant  supporter  la  logique 
operatoire  de  la  fonction  (figure  2). 

Evolutions  des  modules  specialises 

Les  modules  specialises  ont  subi  deux 
evolutions  : 

1)  les  traitements  elementaires  utiles  a  plusieurs 
modules  specialises  ont  ete  regroupes  pour 
former  une  base  d'algorithmes  accessibles  a 
tons, 

2)  les  modules  specialises  assurent  seuls 
I'elaboration  d'un  itineraire  4D  complet 
correspondant  a  un  type  de  reconfiguration 
donne  en  gerant  les  appels  aux  traitements 
elementaires  necessaires. 

Chaque  module  specialise  est  ainsi  responsable 
d'un  type  de  modification  de  I'itineraire 
directement  issu  des  recueils  d'expertise  et 
aisement  identifiable  dans  cette  expertise. 

Evolutions  du  controle 

De  nombreuses  architectures  ont  ete  proposees 
afm  de  doter  des  systemes  de  replanification  de 
capacites  temps  reel. 

Dans  ces  architectures  de  replanification 
reactive,  deux  types  de  plans  sont  souvent 
manipules.  Le  premier  type  est  celui  objet  de  la 
replanification.  Dans  notre  cas,  les  plans  de  ce 
premier  type  sont  les  plans  de  vol  et  les 
itineraires  objets  des  reconfigurations. 

Le  second  type  de  plans  decrit  I'activite  interne 
du  systeme  de  replanification.  Les  actions  du 
second  type  sont  des  actions  de  modification  de 
plans  du  premier  type.  La  replanification 
s'appuie  ainsi  elle-meme  sur  I'execution  de 


plans.  On  parle  alors  de  plans  de  controle  pour 
designer  ces  plans  du  second  type. 

Dans  un  contexte  temps  reel  les  plans  de 
controle  s'averent  etre  un  outil  efficace  de 
gestion  de  I'activite  du  systeme.  Les  techniques 
de  controle  des  systemes  de  replanification 
rejoignent  ici  les  techniques  de  controle  des 
systemes  de  multi-agents  de  type  tableau  noir. 
Les  plans  de  controle  presentent  I'avantage 
d'etre  des  structures  de  donnees  aisement 
modifiables  et  lisibles  et  permettent  de  maitriser 
le  nombre  d'etapes  de  raisonnement  effectuees 
(un  plan  a  un  longueur  ou  une  profondeur  fmie 
et  connue). 

La  tache  principale  du  controle  consiste  alors  a 
determiner  a  tout  instant  les  plans  de  controle  a 
mettre  en  oeuvre  compte  tenu  des  evenements 
a  trailer,  de  leurs  echeances  et  importances 
respectives. 

Les  plans  de  controle  sont  analogues  a  des 
sources  de  connaissances  dont  le  role  n'est  pas 
d'elaborer  des  informations  d'aide  au  pilote 
mais  de  defmir  la  strategic  pour  elaborer  au 
mieux  ces  informations.  Le  superviseur  trade 
ainsi  les  plans  de  controle  comme  des  sources 
de  connaissance  activables  au  meme  litre  que 
les  autres. 

Les  evenements  en  entree  du  superviseur  sont 
transformes  en  buts  a  atteindre  associes  a  une 
priorite  de  traitement.  Le  superviseur  recherche 
ensuite  le  meilleur  plan  de  controle  sachant 
trailer  le  but.  La  mise  en  oeuvre  de  ce  plan 
conduit  a  I'activation  de  SC  ou  d'autres  plans  de 
controle. 

Cette  architecture  a  ete  implementee  et  est 
actuellement  en  cours  de  test.  Sa  modularite 
devrait  favoriser  I'adaptabilite  de  la  fonction 
aux  modifications  d'expertise,  de  type  de 
mission  ou  de  theatre  d'operation 
(principalement  a  travers  la  definition  des  buts, 
plans  de  controle  des  SC  et  des  objets  present 
sur  le  IN).  Cette  capacite  a  s'adapter  s'appuie 
aussi  sur  la  methodologie  et  les  outils  de 
developpement. 


4.  Methodologie  de  developpement 

Ce  paragraphe  aborde  differents  aspects  de  la 
methodologie  de  developpement  de  systeme  de 
gestion  de  mission  et  propose  une  approche 
pratique  issue  de  I'experience  de  tels 
developpements.  Cette  approche  vise  en 
particulier  a  ameliorer  la  reactivite  de  prise  en 
compte  des  besoins  et  de  I'expertise  des  pilotes. 
On  s'interesse  ici  aux  problemes  lies  aux 
specificites  fonctionnelles  et  techniques  de  ces 
systemes  sans  prendre  en  compte  a  ce  stade  les 
contraintes  de  I'embarcabilite  sur  la 
methodologie  de  developpement. 

4.1.  Adaptation  du  cycle  de 
developpement 

La  pratique  du  developpement  de  prototypes  de 
systemes  de  gestion  a  pennis  de  clarifier  les 
etapes  de  developpement  necessaires,  les 
relations  entre  ces  etapes  et  le  role  des 
differents  modeles  utilises.  Cela  conduit  aux 
etapes  de  developpement  representees  Figure  3. 

II  s'agit  en  fait  d'une  adaptation  du  processus  de 
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developpement  en  V.  On  se  demarque  done  ici 
des  processus  de  developpement  centres  sur 
I'acquisition  et  I'implementation  iterative  de 
connaissances  avec  une  representation  des 
connaissances  souvent  determinee  a  priori 
(regies  par  exemple). 

Au  contraire,  on  cherche  ici  a  privilegier  la 
definition  du  systeme  au  choix  d'une 
representation  des  connaissances  ou  d'une 
technique  d'implementation,  les  connaissances 
recueillies  contribuant  aux  etapes  "classiques" 
de  developpement. 

Ce  schema  permet  en  particulier  d'expliciter  les 
roles  respectifs  des  taches  de  recueil  et 
formalisation  d'expertise  vis-a-vis  des  taches  de 
specification  et  d'implementation. 

L'information  issue  des  recueils  d'expertise  est 
utilisee  en  premier  lieu  pour  I'analyse  des 
besoins  de  I'utilisateur  et  oriente  ainsi  la 
specification  du  systeme.  Celle-ci  s'appuie  par 
ailleurs  sur  une  connaissance  des  principes 
d'assistance  etudies  ou  preconises  dans  le 
domaine  de  I'assistance  au  pilotage  (repartition 
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statique  ou  dynamique  des  taches,  aide  a 
I'anticipation,  detection  d'erreurs, 

reconnaissance  d' intentions). 

Partant  de  cette  specification,  le  developpement 
du  systeme  pourrait  se  poursuivre  de  faqon 
conventionnelle.  Le  choix  se  fait  an  moment  de 
la  conception  qui  determine  les  solutions 
techniques  permettant  de  realiser  la 
specification.  Concretement  la  conception 
aboutit  a  la  definition  d'une  architecture 
logicielle  et  de  modules  logiciels.  Selon  les 
problemes  fonctiormels  a  resoudre  on  peut  faire 
appel  soit  a  des  modules  logiciels 
conventionnels  soit  a  des  modules  a  base  de 
connaissance  mettant  en  oeuvre  les  techniques 
de  raisonnement  adaptees  (deduction, 
raisonnement  a  base  de  cas,  resolution  de 
contraintes,  parcours  d'arbres  de  decision,  etc) 
et  les  representations  associees. 

Si  la  conception  fait  apparaitre  de  tels  modules 
a  base  de  connaissance  alors  les  connaissances 
recueillies  trouvent  une  seconde  utilisation  en 
alimentant  ces  modules.  La  definition  de  leur 
role  permet  d'isoler  les  connaissances  utiles  et 
on  considere  qu'un  changement  de 
representation  est  necessaire  a  ce  stade  afm  de 
respecter  les  choix  de  conception  en  matiere  de 
representation  des  connaissances.  L'etape  de 
codage  comporte  alors  une  part  (de  taille 
variable  selon  les  systemes)  consacree  a 
I'implementation  des  connaissances  exploitees 
par  ces  modules. 

Cela  conduit  par  ailleurs  a  distinguer  un  modele 
d'expertise  pilote  independant  de  tout  systeme 
(et  dont  le  formalisme  n'est  pas  lie  a  telle  ou 
telle  technique  d'implementation)  et  un  ou 
plusieurs  modeles  dependant  de  la  conception 
et  destines  a  I'implementation. 

4.2.  Traitement  des  recueils  d'expertise 

Les  recueils  d'expertise  et  leur  analyse  sont 
souvent  consideres  comme  des  taches 
couteuses.  Deux  types  de  difficultes  sont 
evoquees  ici  et  des  solutions  proposees. 


Une  premiere  source  de  difficulte  provient  de  la 
taille  considerable  des  corpus  constitues  rendant 
leur  utilisation  quotidienne  fastidieuse.  On 
cherche  done  legitimement  a  utiliser  un 
formalisme  pour  synthetiser  les  connaissances 
recueillies  tout  en  garantissant  coherence  et 
completude.  Or,  cette  formalisation  peut  se 
reveler  difficile  a  utiliser  car  tres  dense  et 
parfois  impenetrable  pour  un  lecteur  exteme. 
Ainsi,  une  autre  forme  plus  lisible  et  facilitant 
la  communication  a  ete  defmie.  II  s'agit  de  ce 
que  nous  appelons  une  synthese  par  themes 
regroupant  I'ensemble  des  elements  de 
connaissances  (description  d'un  objet,  d'un 
probleme,  d'une  strategie  de  resolution) 
presents  dans  un  corpus.  Chaque  element  est 
reference  par  rapport  au  corpus  et  peut 
appartenir  a  plusieurs  themes  evitant  ainsi  toute 
classification  rigide. 

La  formalisation  est  ensuite  effectuee  a  partir 
des  syntheses  par  themes.  Cela  permet  un  gain 
de  temps  appreciable  car  les  redundances  et 
contradictions  apparentes  du  corpus  et 
I'eparpillement  des  informations  traitant  d'un 
meme  theme  ont  ete  traites  par  la  constitution 
de  ces  syntheses. 

Une  seconde  source  de  difficulte  pour  le 
cogniticien  provient  de  la  difficulte  a  converger 
vers  une  comprehension  coherente  des  propos 
de  I'expert  creant  le  besoin  d'iterer  sur  certains 
sujets.  On  constate  ainsi  frequemment  des 
problemes  d'interpretation  dus  a  un  manque  de 
precision  concernant  les  hypotheses  sous- 
jacentes  aux  questions  posees.  Ces  hypotheses 
implicites  ont  toutes  les  chances  d'etre 
differentes  entre  le  cogniticien  et  I'expert. 

Cela  nous  a  conduit  a  defmir  un  protocole 
d'entretien  imposant  une  definition  tres  precise 
du  contexte  de  I'entretien.  Ce  contexte 
comprend  un  ensemble  de  36  parametres 
explicites  avec  I'expert  en  debut  d'entretien. 
Parmi  ces  parametres  :  le  type  d'avion 
considere,  ses  principaux  equipements,  son 
armement,  le  type  de  dispositif,  le  contexte 
tactique  et  operationnel,  une  mission  type  a 
effectuer. 
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Les  reponses  obtenues  ne  sont  considerees 
valides  que  dans  ee  contexte  et  un  travail  de 
generalisation  est  ensuite  necessaire  afin 
d'analyser  1' influence  d'un  parametre  du 
contexte  sur  les  reponses  obtenues. 

Get  effort  de  precision  a  permis  de  clarifier  ce 
qui  apparaissait  a  tort  comme  des  incoherences 
du  discours  de  I'expert  ou  des  incoherences 
entre  plusieurs  experts  interroges  sur  le  meme 
sujet. 

Le  developpement  d'un  support  informatique 
plus  puissant  (gestion  documentaire  hypertexte 
avec  fonctions  dediees)  doit  permettre  de 
developper  cette  approche. 

5.  Evaluation 

5.1.  Methodologie  d'evaluation 

La  simulation  de  la  fonction  Gestion  de 
Mission  actuellement  en  cours  de 
developpement,  doit  etre  evaluee  par  les  pilotes 
des  Etats  Majors  de  I’Armee  de  I’Air  et  de  la 
Marine  Nationale  qui  ont  contribue  aux  recueils 
d’expertise. 

Cette  evaluation  a  lieu  sur  les  moyens  du  banc 
de  simulation  de  concepts  de  conduite  du  vol  de 
SEXTANT  Avionique  sur  la  base  de  scenarii  de 
missions  Air/Sol  defmis  avec  les  Operationnels 
au  cours  des  recueils  d'expertise. 

Le  systeme  implante  sur  le  banc  de  simulation 
permet  au  pilote  d’ observer  les  trajectoires 
solutions  proposees  pour  remedier  a 
T  apparition  d’imprevus  apparus  a  tout  moment 
dans  le  deroulement  de  la  mission,  tout  en 
continuant  de  piloter  Tavion.  Le  pilote  voit  son 
avion  evoluer  sur  T  image  graphique  du  theatre 
des  operations  apparaissant  sur  I’ecran  place 
dans  le  cockpit  devant  lui.  II  pent  selectionner 
la  trajectoire  qu’il  souhaite  suivre  et  embrayer 
son  pilote  automatique  afm  d’etre  guide  sur 
celle-ci. 

5.2.  Environnement  d'evaluation 

SEXTANT  Avionique  dispose  d'un  banc  de 
simulation  pour  applications  militaires  capable 


d'accueillir  de  nouveaux  concepts  de  pilotage 
sous  forme  de  fonctions  logicielles. 

Ce  banc  comporte  la  simulation  d'un 
environnement  avion  "grands  mouvements" 
avec  ses  moteurs,  ses  capteurs  principaux  et  ses 
moyens  de  radio-navigation. 

5.2.1.  Architecture  materielle 

L'architecture  materielle  se  compose  : 

-  d'un  "cockpit"  de  pilotage  dote  de  moyens 
simules  de  pilotage  de  base  (manche,  manette) 
et  de  visualisations  multifonctions  tete  haute, 
moyenne,  et  laterales, 

-  d'une  simulation  de  paysage  3D, 

-  de  calculateurs  temps  reel  connectes  entre  eux 
par  une  liaison  haut  debit, 

-  d'un  ensemble  de  stations  de  travail  supportant 
la  fonction  Gestion  de  Mission  et 
communiquant  selon  la  norme  CORBA. 

5.2.3.  Architecture  fonctionnelle 

La  simulation  est  composee  de  quatre  blocs 
fonctionnels  : 

-  bloc  Base  De  Donnees  constitue  par: 

-  un  fichier  TERRAIN  complet  "altimetrie  et 
planimetrie" 

-  une  base  de  dormees  Plans  De  Vol 

-  une  base  de  donnees  BUTS 

-  une  base  de  donnees  SIT  AC  (tactique) 

-  une  base  de  donnees  METEO 

-  bloc  Avion  et  Systeme  constitue  par 

-  I'environnement  Avion  Moteur  Capteurs 

-  la  fonction  de  pilote  automatique 

-  la  gestion  du  cockpit  de  pilotage 

-  la  conduite  de  la  simulation 

-  bloc  IHM  : 

-  visualisations  tete  moyenne,  tete  laterales 
developpees  en  environnement  graphique 
Xll, 

-  bloc  Noyau  Fonctionnel  qui  comprend: 

-  un  superviseur 

-  des  modules  specialises 
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-  I'embarcabilite  de  la  fonction  sous  les  aspects 
La  figure  4  represente  I'architecture  materielle  technologique,  methodologique  et 

et  logicielle  et  schematise  les  flots  de  donnees.  reglementaires. 


figure  4  Architecture  de  la  simulation 


6.  Conclusion 

La  presente  publication  decrit  les  travaux 
recents  realises  par  SEXTANT  Avionique  dans 
le  domaine  de  la  Gestion  de  Mission.  Une 
fonction  d'assistance  a  la  gestion  de  la  mission 
est  presentee  en  terme  de  fonctionnalites 
d'assistance,  d'architecture  et  de  methodologie 
de  developpement.  La  recherche  de  gain 
d'adaptabilite  grace  aux  choix  d'architecture  et 
de  methodologie  est  mis  en  evidence.  Les 
travaux  a  venir  a  court  terme  conceme 
revaluation  en  simulation  pilotee  de  la  fonction. 
Par  ailleurs,  les  axes  de  developpement  incluent 
egalement : 

-  I'extension  du  domaine  d'emploi  de  la  fonction 
(autres  theatres  operationnels,  autres  types  de 
missions), 

-  le  renforcement  des  moyens  ou  techniques 
favorisant  cette  extension  par  la  definition  et  la 
mise  en  place  d'outils  informatiques 
complementaires  en  support  du  cycle  de 
developpement  presente. 
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MISSION  PLANNING  SYSTEMS:  CUBIC  MULTIPLIERS 
by 

R.P.  de  Moel,  E.J.  Heerema 
National  Aerospace  Laboratory  (NLR), 

PO  Box  90502  1006  BM  Amsterdam,  The  Netherlands 


1  Introduction 

AGARD  Advisory  Report  No.  296,  published  May  1991, 
contains  the  definition  of  a  planning  system  for  aircraft 
missions:  "A  system  that  allows  all  the  available  ahd 
pertinent  information  to  be  used  to  plan  a  mission  to 
achieve  certain  objectives  in  an  optimum  and  near¬ 
optimum  way,  and  also  data  that  describes  the  mission  to 
be  loaded  into  the  aircraft.  With  respect  to  objectives, 
operating  and  technology  mission  planning  systems  can  be 
considered  as  multipliers."  This  paper  discusses  some 
topics  related  to  these  multipliers. 

The  National  Aerospace  Laboratory  NLR,  in  The 
Netherlands,  has  a  long  time  experience  in  development 
and  production  of  military  aircraft  mission  planning 
systems  (figures  1  and  2).  In  1975  already  NLR  studied 
the  feasibility  of  "rear-port  tube"  graphic  display  systems 
for  mission  planning  purposes.  This  type  of  display  system 
provided  the  capability  to  project  map  information  via  a 
rear-port  on  the  innerside  of  the  display  screen,  so  the 
screen  itself  could  be  applied  to  compose  and  show  an 
overlay  on  the  projected  map.  However,  inadequate 
positioning  accuracy  of  the  overlay  on  the  map  with 
respect  to  navigation  requirements  made  this  rear-port 
tube  graphics  technology  unfeasible  for  military  aircraft 
mission  planning  systems.  NLR’s  assessment  of  technology 
improvements  is  part  of  the  section  on  technology  (section 
4). 

The  most  prominent  multiplier  is  directly  related  to  the 
mission  objectives.  Awareness  of  the  actual  battle  theatre 
and  several  types  of  advices  (weapon  -  to  -  mission 
objectives  suitability,  minimum  risk  route,  attack 
manoeuvring  etc.)  are  improving  principally  and 
practically  the  chances  on  mission  success.  Section  2  of 
this  paper  highlights  two  ingredients  of  this  multiplier: 

in  the  framework  of  interoperability  the 
standardization  of  data  exchange; 
in  the  framework  of  user  friendliness  a  user 
definable  electronic  continuous  map  area. 

The  second  multiplier  is  the  capability  of  mission  planning 
systems  to  play  a  role  in  the  training  of  military  pilots 
with  respect  to  the  execution  of  real  missions.  To  make 
this  multiplier  effective  three  conditions  have  to  be 
fulfdled: 

the  mission  planning  system  supports  all  mission 
types  due  to  be  exercised; 

a  metric  system  is  available  to  assess  the  planned 
and  sometimes  also  executed  missions  in  detail; 
fake  realistic  battle  theatres  are  composed  in  such 
a  way  that  progress  in  training  can  be  determined. 
This  second  multiplier  will  be  discussed  in  section  3. 


Mission  planning  systems  are  driving  the  technology:  the 
third  multiplier.  Routing  systems  need  always 
geographic/topographical/reconnaissance  information  and 
this  information  mass  is  e.g.  driving  storage  capabilities, 
data  compression  techniques,  and  remote  sensing 
derivatives.  This  subject  will  be  discussed  in  section  4. 

2^  The  first  multiplier:  improved  mission  execution 

An  electronic  information  system  exists  of  three 
components:  hardware,  software  and  information.  These 
three  components  are  all  essential:  the  quality  of 
information  defines  for  the  mayor  part  the  value  of  the 
multiplier.  A  large  part  of  this  information  is  either 
unchanging  or  very  slowly  changing,  so  that  update  of  this 
is  rarely  necessary  and  in  no  way  critical.  However  some 
of  the  information  -  e.g.  the  geographical  position  of  both 
friendly  and  enemy  assets  -  could  be  changed  frequently  to 
correspond  to  rapidly  changing  real  world  situations. 

2,1  NATO  standards  for  data  exchange 

The  mobility  of  military  forces  -  needed  because  of  an 
essential  task  of  NATO:  embanking  of  local  conflicts  -  and 
the  improved  mobility  of  enemy  threats  hamper  obtaining 
correct  and  up-to-date  information.  Of  course  it  is  an 
option  to  prepare  a  mission  without  using  this 
information:  in  that  case  a  judicious  risk  analysis  is 
recommended.  The  NATO  approach  to  facilitate  the 
transfer  of  information  is  to  define  "exchange  standards”: 
standard  information  formats. 

What  NATO  data  exchange  standards  are  available  to 
load  this  pertinent  information  (see  table  1)  into  the 
mission  planning  data  base?  This  investigation  is  limited  to 
the  information  sets  in  the  scenario  cluster,  because  of  the 
rapidly  changing  character  of  most  of  these  information 
sets.  The  first  column  of  table  2  contains  the  name  of  the 
information  subset  involved,  the  second  column  the 
number  and  the  edition  of  the  NATO  Standard  Agreement 
(STANAG),  the  third  column  the  designation  and  covering 
of  the  related  standard. 

Table  2  shows  that  only  for  geographical  information  data 
exchange  STANAGs  have  been  defined.  The  important 
intelligence  data  STANAG  is  a  concept  version;  for  meteo 
only  a  communication  STANAG  is  available.  For 
navigation  data  a  STANAG  for  obstacles  is  available.  In 
the  framework  of  data  exchange  standards  for  command 
and  control  still  a  lot  of  work  has  to  be  done. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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Table  1  MSS/P  DATABASE 


information  breakdown 

Scenario  cluster 


Geographical  info. 

Digital  Landmass  SYSTEM 
1:50/100/250,000  electr.  maps 
1 :500,000  electronic  maps 
1:2,000,000  electronic  maps 
Schematic  maps  (WVS) 
Intelligence  Into. 

Threats* 

Planning  lines* 

Nuclear  incidents* 
Meteorological  info. 

Airfield  weather* 

Significant  weather  chart* 
Aircraft  performance  weather* 

Navigation  info. 

Airspace  management* 

Low  flying  restrictions 
Obstacles 


terrain  elevation  and  feature  data 
continuous  areas 
continuous  areas  (TPC,  LFC) 
map  sheets 


AOB,  EOB,  GOB,  MOB,  Events,  Latent  threat 
including  PLOT,  FSCL,  EFSCL,  RIPL 


actual  and  forecast 
lines,  symbols  and  text 

^rW^osition,  wind  speed/direction,  temperature, 

routes,  zones,  lines,  boundaries,  traverse  levels 
lines,  areas,  circles 
Elevations  in  AGL  and  MSL 


Friendly  airfields  status  of  ATC,  runway,  weather,  X-serv. 

Airfield  ICAO  codes  position  and  capabilities 

Standard  waypoints 

Flight  information  regions  region  identifiers  -(■  latitudes/longitudes 

Magnetic  corrections 


remarks 


UTM  projection 
Lambert  projection 
Lambert  projection 
DMA  product 

point  co-ordinates 
split  up  in  line  parts 
for  presentation  only 


mainly  for  Ferry  a/c  performance 
calc. 

validity  periods 
validity  periods 

limited  availability  for  low  level 
flights 

necessary  for  diversion 

to  support  fast  planning 

for  air  traffic  control  in  peace 

time 

predicted  for  5  years 


Aircraft  and  weapon  cluster 

Aircraft  performance 

Aircraft  configuration  tailnumber  specific  and  generic 

Weapon  Stores  config.  aircraft/station/stores  standard,  pilot  selectable 


implemented  as  software  library 

standard  configurations  can  be 
predefined 


Tactics  cluster 

Tactical  scenario 

Weapon  effectiveness 
Manoeuvres 

Route  (Preplanned) 
Communications 


altitude  bands,  risk  levels,  EW  conditions, 
threat  type 

predefined  by  NATO,  local  adaptations  possible 
run-in,  attack,  delivery 

air-to-ground  missions,  air  defence  sectors,  CAP-pos. 
including  IFF/SIF  codes 


threat  presentation  and 
calculation 

fuse  arming/safe  escape/ 
fragmentation 


risk 


Default  and  control  parameters 

Defaults  to  speed  up  standard  planning 

sessions 

Control  parameters  ID.  of  info,  source,  map  scale/type  and  symbols  user  friendliness 


*  also  obtainable  from  other  CCIS 
systems 


Table  2  NATO  DATA  EXCHANGE  STANDARDS 


Information  subset 

STANAG 

Remarks 

Geographical 
-  terrain  elevation 

3809 

(ed.  3,  1995) 

MIL-D-89020 

-  feature  analysis 

- 

MIL-D-89006 

-  electronic  maps  NATO 

4387 

(concept) 

ASRP 

DOD 

- 

MIL-A-89009  ADRG 

-  digital  maps 

7074 

(ed.  1,  1995) 

DIGEST 

Intelligence 

2433 

(concept) 

AlntP3 

Meteo 

6014 

(ed.  2,  1995) 

AWP3(A),  only  communications 

Navigation 

-  airspace  management 

ATP  40  (A),  1989 

-  low  flying  restriction 

- 

CALF,  AFCENT 

-  obstacles 

2123 

(ed.  3,  1988) 

obstacle  folder 

-  friendly  airfield 

- 

ICAO 

-  airfield  ICAO  codes 

- 

ICAO 

-  standard  waypoints 

- 

- 

-  flight  info  regions 

- 

ICAO  Doc.  8400/3 

-  magnetic  corrections 

- 

British  Geological  Survey 
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2.2  NATO  standards  for  geographical  data  exchanges 
and  userfriendlincss 

The  geographical  STANAGs  mentioned  in  table  2  are  used 
mainly  for  data  exchange.  What  effort  has  to  be  spent  to 
make  this  exchange  data  ready  for  use?  The  three 
geographical  subsets  under  consideration  will  be  discussed 
separately. 

2.2.1  Digital  Terrain  Elevation  Data  fPTED) 

Each  terrain  elevation  is  compressed  into  two  36-bits 
words,  the  file  size  is  a  1-degree  by  1-d^ree  geographical 
cell.  The  conversion  effort  is  defined  by  the  collection  of 
the  required  cells  and  the  decompression  into  usable  items. 
It  is  recommendable  to  spend  this  effort  once  prior  to  the 
use  of  the  information  in  the  application. 

2.2.2  Electronic  maps 

Table  2  shows  two  exchange  standards  for  electronic 
(raster)  maps.  The  first  one  is  the  DMA  exchange 
standard,  adopted  by  the  USA  DOD  specifications  under 
MIL-A-89007.  NATO  has  not  copied  this  standard 
completely  but  defined  STANAG  4387.  A  significant 
difference  between  both  standards  is  the  defined  raster 
resolution  (MlL-A-9007:  250  pixels/inch,  STANAG  4387: 
more  flexible,  nominal  250  pixels/inch,  variations 
allowed). 

Both  standards  for  arc  raster  products  data  exchange  are 
dealing  with  the  conversion  of  paper  map  sheets  into 
electronic  map  sheets  in  a  non-equidistant  projection 
system.  If  the  user  requirements  for  the  mission  planning 
system  are  satisfied  by  separate  non-equidistant  electronic 
map  sheets,  there  is  no  effort  needed  any  more.  In  case 
the  user  requirements  for  the  mission  planning  system  are 
requesting  scrolling  over  a  continuous  area  (a  number  of 
electronic  map  sheets  defined  by  the  operational  user),  a 
considerable  effort  is  necessary. 

The  above  mentioned  scrolling  requirement  is  most  of  time 
due  to  combined  tactical  objectives:  overview  of  (attack) 
scenario  and  a  high  level  of  detail  for  mission  success. 
Especially  if  1:50,000;  or  1:100,000  scale  maps  are  needed 
for  the  level  of  detail;  map  sheets  have  to  be  glued 
together  for  overview  purposes. 

The  effort  to  glue  maps  together  is  considerable  due  to: 

the  required  navigation  accuracy  in  attack 
manoeuvring; 

variations  in  map  sheet  sizes  and  in  colour 
definitions  caused  by  the  traditions  of  the  national 
geographical/topographical  services; 
deviations  (e.g  bulges  exceeding  the  defined  map 
sheet  size)  and  defects  of  paper  map  sheets  (e.g 
smaller  than  the  specified  area,  or  folded). 

The  NLR  Electronic  Map  Area  Production  System 
(EM APS)  copes  with  these  problems  (figure  3). 

2.2.3  Digital  Mans 


attributes  for  each  map  item.  Already  a  long  time  the  user 
community  is  waiting  for  this  digital  map  information  with 
a  high  expectation  level.  It  cannot  be  avoided  that  these 
users  will  be  disappointed. 

This  disappointment  is  caused  mainly  by  the  lack  of  real 
user  requirements.  The  national  topographical/ 
geographical  services  contributed  to  the  STANAG  in  such 
a  way,  that  the  digital  geographical  information  may  be 
used  to  reconstruct  the  original  map  sheet.  The 
topographical/geographical  services  will  have  the  full 
profit  of  the  much  better  update  possibility. 

If  the  user  needs  with  respect  to  geographical  information 
are  satisfied  by  separate  sheets,  there  is  no  effort  needed 
any  more.  Just  the  same  as  for  electronic  maps.  The 
advantage  for  the  user  will  be  that  the  map  producer  is 
able  to  provide  updates  faster  and  at  lower  cost.  If  the 
user  needs  are  requesting  continuous  map  areas,  the  effort 
to  realize  these  areas  can  not  yet  be  estimated  due  to  the 
lack  of  experience.  It  is  not  impossible  that  electronic 
maps  will  be  used  for  a  longer  period  than  previously 
expected. 

3i  The  second  multiplier:  uniform  training  in  mission 
execution 

After  the  pilot  obtained  his  flying  certificate,  he  needs  an 
additional  training  in  order  to  become  a  competent 
mission  executor.  The  employment  of  a  mission  planning 
system  in  this  training  for  mission  execution  has  several 
advantages: 

uniformity  in  training  is  improved; 

uniformity  in  presentation  of  battle  theatre  is 

assured; 

exercises  can  be  repeated  easily,  also  after 
completion  of  the  training. 

In  the  introduction  of  this  paper  three  conditions  have 
been  mentioned.  The  mission  planning  system  needs  to 
support  all  mission  types  that  have  to  be  trained  and 
exercised;  this  includes  of  course  the  airforce  specific 
tactics  in  mission  execution.  The  way  to  consider  the  other 
two  conditions  (metrics  and  fake  scenario)  is  to  take  them 
together.  Fake  realistic  scenarios  have  to  be  built  in 
increasing  difficulty  level  and  a  appreciation  Hgure  is 
attached  in  case  the  mission  execution  problem  has  been 
solved  properly. 

4.  The  third  multiplier:  technology  driver 
The  second  paragraph  of  the  introduction  tells  the  story  of 
the  rear-port  tube  graphic  systems,  being  at  that  time  the 
only  possibility  to  present  multicolor  maps  to  the  user. 
Disapproval  -  due  to  the  required  navigation  accuracy  - 
postponed  the  presentation  of  multicolor  maps  for  mission 
planning  for  several  years.  Table  3  shows  the  evolution  of 
the  peripherals/workstations  for  the  mission  planning 
systems  developed  by  NLR. 


STANAG  7074  provides  the  rules  for  the  transfer  formats 
of  geographical  information  existing  of  coordinates  and 
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Tahle  3:  EVOLUTION  OF  MISSION  PLANNING  WORKSTATIONS 


MOT&E  System 
(1979  -  19811 

«  a-N  display 
•  printer 


Phase  1  +  Pilot 
System  (1981  -  1995) 

•  a-N  display 

•  printer 

•  colour  graphics 


display 


•  digitizer 
(1x1 .4  m) 


S.O.  CAMPAL 
System  (1985  -  1988) 

•  a-N  display 

•  graphics  printer 

•  2D  colour  image 


display 

(1024x1024  pixels) 

•  digitizer 
(1x1 .4  m) 

•  colour  hard  copy 

unit  (A3) 


MSS/CAMPAL 
(1991  -  1994) 


•  3D  colour  graphics 


display 

(1280x1024  pixels) 


•  colour  hard  copy 
unit  (A3) 


MSS/PANDORA 
(1996  -  ) 


•  3D  colour 
graphics 

display 

(1 280x1 024 
pixels) 


•  colour  hard 
copy 

unit  (A4/A3) 


Also  the  technology  progress  of  for^round/hackground 
memory  and  computer  speed  played  a  significant  role. 
Some  examples: 

MSS/Campal  has  a  1  Gigabyte  harddisk  and  a  1 
Gigabyte  optical  disk;  MSS/Pandora  has  a  8 
Gigabyte  harddisk  and  no  optical  disk  any  more; 
resiMtnse  time  for  geographical  information  have 
been  decreased  from  some  minutes  to  some 
seconds; 

tbe  current  computing  speed  enables  scrolling  of 
geographical  information  at  a  speed  of  8Hz. 

"Computer  based  mission  planning  is  a  technology  driver" 
is  the  statement.  For  the  time  being  this  statement  remains 
valid.  Mission  planners  want  to  have  a  overview  over  the 
entire  (mission)  area  of  interest.  To  the  opinion  of  some 
operational  users  scrolling  is  only  a  poor  replacement  for 
this  overview.  The  requested  screen  size  is  about  1  meter 
by  1  meter.  More  computer  speed  is  needed  because  of  3D 
terrain  presentations  and  verification  of  terrain  coverage 
during  low  flying  (fixed  wing  and  rotorwing  aircraft). 

^  Concluding  remarks 

The  cubic  multiplier  statement  is  discussed  only  for 
ground  based  mission  planning  systems.  In  the  case  the 
mission  planning  task  is  split  over  a  ground  based 
component  and  an  aircraft  component  tbe  statement  is  not 
changing  essentially. 

The  significance  of  mission  planning  systems  is 
demonstrated  at  the  most,  if  the  tasked  mission  is 
complicated  and  has  to  be  executed  in  a  complex  and 
relatively  unknown  area.  To  experience  the  multiplier  in 
extreme  circumstances,  training  in  more  simple 
circumstances  is  highly  recommended. 


^  Acronyms 


ADRG 

Arc  Digital  Raster  Graphics 

AFCENT 

Allied  Air  Forces  Central  Europe 

AGARD 

Advisory  Group  for  Aerospace  Research 
and  Development 

AGL 

Above  Ground  Level 

AlntP 

Allied  Intelligence  Publications 

AOB 

Air  Order  of  Battle 

ASRP 

Arc  Standard  Raster  Product 

ATC 

Air  Traffic  Control 

ATP 

Allied  Tactical  Publication 

AWP 

Allied  Weather  Publication 

CALF 

Chart  Amendment  Low  Flying 

CAMPAL 

Computer  Aided  Mission  Preparation  at 
Airbase  level 

CAP 

Combat  Air  Patrol 

CCIS 

Command  and  Control  Info.  System 

DIGEST 

Digital  Geographical  Standard 

DMA 

Defense  Mapping  Agency 

DOD 

Department  of  Defense 

DTED 

Digital  Terrain  Elevation  Data 

EFSCL 

Emergency  Fire  Support  Coordination 
Line 

EMAPS 

Electronic  Map  Area  Production  System 

EOB 

Electronic  Order  of  Battle 

EW 

Electronic  Warfare 

FLOT 

Forward  Line  Own  Troops 

FSCL 

Fire  Support  Coordination  Line 

GOB 

Ground  Order  of  Battle 

ICAO 

International  Civil  Aviation 

Organization 

IFF 

Identification  Friend  of  Foe 

LFC 

Low  Flying  Chart 

MOB 

Missile  Order  of  Battle 

MSL 

Mean  Sea  Level 

MSS 

Mission  Support  System 

MSS/C 

MSS/CAMPAL 

MSS/P 

MSS/PANDORA 

NATO 

North  Atlantic  Treaty  Organization 

NLR 

National  Aerospace  Laboratory  NLR 

PANDORA 

Planning  of  Aircraft  Navigation  for 
Defensive,  Offensive  and 

Reconnaissance  Airtasks 

QNH 

Airpressure  (milibar)  above  MSL 

RIPL 

Reconnaisance  and  Interdiction  Planning 
Line 

SIF 

Selective  Identification  Feature 

S.O.  CAMPAL 

Semi-operational  CAMPAL 

STANAG 

Standard  NATO  Agreement 

TPC 

Tactical  Pilotage  Chart 

UTM 

Universal  Transverse  Mercator 

WVS 

World  Vector  Shore  Line 
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Systeme  d'enregistrement  et  restitution  de  mission 

F.X.  Parisot 
SAGEM  S.A. 

Eragny  B.P.  51 

F-95612  Cergy-Pontoise  cedex 
France 


SUMMARY 


SAGEM  S.A.  company  presents  an  architecture  for  embedded  recording  of  multiple  video  signals  and  digital 
data  on  an  single  tape,  and  their  ground  restitution. 

The  System  Emports  Interface  Box  (BISE)  is  an  hardened  equipment,  mounted  on  ACE/Rafale  aircraft.  It 
manages  all  interfaces  between  aircraft  and  stores,  following  the  MIL-STD-1760  standard:  digital  buses,  video 
signals  and  synchronisation/blanking  signals.  One  of  its  function  is  to  realize  the  time  multiplexing  and  data 
marking  of  several  video  signals,  for  mission  recording  on  magnetic  tape. 

A  ground  PC-based  equipment  has  been  developped  in  parallel  for  the  restitution  of  these  video  signals  and 
data.  Some  data  are  used  to  synchronize  the  visualization  of  the  video  source  choosen  by  the  operator. 

The  considered  evolutions  of  this  architecture  are  discussed,  with  digital  video  recording  and  restitution. 

A  new  concept  is  also  proposed,  for  immediate  on-board  video  restitution. 


1.  PRESENTATION 

Le  systeme  embarque  de  conduite  de  mission 
permet  au  pilote  d'exploiter  les  donnees  qui  ont  ete 
preparees  pour  les  differentes  phases  de  sa  mission. 
II  assure  egalement  I'enregistrement  de  mission. 

La  conduite  d'une  mission  est  aujourd'hui  facilitee 
par  la  preparation  qui  en  est  faite  au  sol.  Les 
differentes  actions  et  leur  sequencement  peuvent 
etre  prepares  et  optimises  pour  un  ensemble 
d'appareils.  Apres  la  mission,  sa  restitution  avec 
exploitation  des  donnees  en  rejeu  est  n6cessaire  aux 
operationnels  pour  evaluer  le  niveau  d'obtention  des 
objectifs. 

Outre  ce  premier  niveau  d'exploitation,  la  restitution 
de  la  mission  doit  egalement  servir  a  un  deuxieme 
niveau  pour  evaluer  la  maniere  dont  la  mission  a  ete 


remplie.  Ce  retour  d'experience  doit  servir  a 
optimiser  les  procedures  de  preparation. 

Le  choix  des  donnees  a  enregistrer  pendant  la 
mission  poursuit  done  ce  double  objectif.  Le  nombre 
des  informations  a  enregistrer  est  en  constante 
augmentation,  avec  des  signaux  video  pour  une 
grande  part. 

Nous  presentons  le  materiel  embarque 
d'enregistrement  de  mission  qui  a  ete  developpe 
specifiquement  pour  I'AC E/RAFALE,  ainsi  que  le 
systeme  de  restitution  sol.  Nous  tracerons  les 
perpectives  d'evolution  d'un  tel  ensemble. 

Nous  decrirons  egalement  un  equipement  permettant 
lorsque  necessaire  une  exploitation  de  donnees 
video  immediate  par  le  pilote,  pour  decision  locale 
sur  le  deroulement  de  la  mission. 


Paper  presented  at  the  AGARD  MSP  Symposium  on  "Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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2.  CONTEXTE 

2.1 .  Chaine  fonctionnelle 


L'interet  de  la  preparation  de  mission  est  de  definir  et 
rassembler  les  donnees  de  toute  nature  qui  seront 
utiles  au  pilote,  ou  qui  permettront  au  systeme  de 
conduite  de  mission  de  se  configurer  differemment 
au  fur  et  a  mesure  des  differentes  phases 
programmees.  Les  donnees  dependent  des 
capacites  des  Systemes  de  Navigation  et  d'Attaque 
(SNA)  des  avions,  qui  deviennent  de  plus  en  plus 
complexes  et  necessitent  des  volumes  sans  cesse 
croissants.  Elies  sont  preparees  pour  chaque 
appareil  sur  un  support  de  donnees  extractible, 
comme  des  memoires  silicium  ou  disques  durs 
durcis. 

Pour  permettre  la  restitution  de  mission  et  I'analyse 
operationnelle,  des  informations  sont  enregistrees  a 
bord.  Ce  sont  essentieliement  des  signaux  video  et 
audio,  des  donnees  numeriques  avion  et  des 
evenements.  Ces  informations  sont  stockees  sur  des 
supports  extractibles,  qui  peuvent  etre  ceux  utilises 
pour  les  donnees  d'initialisation. 

L'enregistrement  du  signal  de  plusieurs  sources 
video  (capteurs,  ecrans  piiote,  poste  de  pilotage...) 
necessitait  jusqu'a  maintenant  la  mise  en  place  a 
bord  d'autant  de  magnetoscopes  que  de  signaux  a 
enregistrer.  SAGEM  S.A.  a  d6velopp6  une  fonction 
de  multiplexage  temporel,  permettant  d'enregistrer 
plusieurs  signaux  video  sur  un  seui  magnetoscope. 
Cette  nouvelle  fonction  est  implantee  dans  un 
equipement  qui  a  ete  d6veloppe  pour  I'avion 
ACE/Rafale,  qui  gere  I'interface  du  systeme  de 
navigation  et  d'attaque  avec  les  emports. 


2.2.  Boitier  BISE 

Le  Boitier  d'Interface  Systeme  -  Emports  (BISE)  est 
un  equipement  durci,  embarque  sur  I'avion  d'armes 
ACE/Rafale  de  Dassault  Aviation.  II  est  aujourd'hui 
pret  a  etre  produit  en  serie.  II  gere  toutes  les 
interfaces  entre  le  Systeme  de  Navigation  et 
d'Attaque  de  I'avion  et  les  Emports,  suivant  la  norme 
MIL  STD  1760,  qui  specifie  les  interfaces  des  points 
d'ancrage  des  emports  sur  I'avion,  pour  assurer  de 
plus  en  plus  la  compatibilite  des  emports  avec 
plusieurs  avions. 

Cet  interface  remplit  les  fonctions  de: 

-  gestion  de  donnees.  Une  passerelle  informatique 
assure  le  couplage  entre  le  bus  numerique 
principal  de  I'avion  391 0  et  les  bus  1 553 
desservant  les  emports, 

-  gestion  de  signaux  de  synchronisation  /blanking, 
avec  commutation  de  12  voies  vers  28, 

-  gestion  de  signaux  video  au  standard  Stanag 
3350,  avec  plusieurs  fonctions. 

Les  fonctionnalites  video  BISE  comportent: 

-  la  synchronisation  de  tous  les  signaux  video  de 
I'avion.  Un  signal  de  synchronisation  genere  en 
interne  est  envoye  a  tous  les  equipements  video 
comportant  une  entree  de  synchronisation 
externe.  Le  Boitier  assure  la  synchronisation  de 
signaux  provenant  de  sources  non 
synchronisables. 
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-  la  commutation  de  signaux  video  large  bande 
20  MHz.  Line  matrice  de  commutation  modulaire 
est  composee  de  cartes  a  8  entrees  et  8  sorties, 
permettant  jusqu'a  32  entrees  et  32  sorties,  en 
video  numerique  ou  analogique  large  bande.  Un 
bus  video  interne  diffuse  les  signaux  provenant 
des  entries  sur  les  diferentes  sorties. 

-  la  conversion  de  standard.  Un  signal  525  lignes 
est  convert!  en  625  lignes. 

-  le  formattage  d'informations  pour  enregistrement 
de  mission.  Un  signal  video  standard  est  genere, 
et  envoy6  a  un  magndtoscope  embarque  pour 
enregistrement.  II  comporte  un  multiplexage 
temporel  programmable  par  trame  de  8  sources 
vid6o  monochromes  ou  couleurs  RVB,  ainsi  que 
des  donn6es  numdriques,  marquees  dans 
chaque  trame. 

3.  ENREGISTREMENT  DE  MISSION 


3.1 .  Systems  de  multiplexage  temporel 

Dans  le  systeme  video  625  lignes,  le  rythme  de 
rafraTchissement  des  images  d'une  video  est 
normalement  de  25  images  par  seconds  (Stanag 
3350  classe  B).  Partant  des  constatation  suivantes: 

-  I'importance  opdrationnelle  des  images  des 
differentes  sources  viddo  varie  suivant  les 
diffdrentes  phases  d'une  mission, 

-  certaines  sources  gdnerent  des  images  a  vitesse 
de  variation  lente, 

-  les  opdrateurs  de  restitution  font  pour  une  grande 
part  I'analyse  d'images  fixes  sdlectionndes, 

s'il  est  acceptable  a  la  restitution  de  visualiser  des 
viddos  avec  un  mouvement  Idgerement  saccadd,  le 
multiplexage  temporel  rdussit  une  excellente 
optimisation  de  I'utilisation  de  la  bande  passante  d'un 
magndtoscope  unique,  en  la  distribuant  a  plusieurs 
sources  viddo. 

La  crdation  d'une  mosaique  de  quatre  sources  est 
une  mauvaise  alternative,  car  le  nombre  de  sources 
est  fixe,  et  surtout  la  taille  et  la  qualitd  des  images 
est  rdduite. 

Les  fonctions  de  multiplexage  temporel  de  plusieurs 
signaux  viddo  et  de  marquage  de  donndes 
numdriques  dans  la  viddo  sont  implantdes  sur  une 
carte  de  I'dquipement  BISE. 

Les  sources  viddo  dont  les  signaux  peuvent  etre 
multiplexdes  sont  celles  disponibles  dans  I'avion, 
provenant  de  capteurs  gdndrant  une  image,  de 
boitiers  gdndrateurs  de  symbologie,  ou  des  recopies 
d'dcrans. 


Description  fonctionnelle 

La  carte  permet  de  multiplexer  temporellement,  par 
trames  ou  images,  huit  sources  trichromes  RVB  ou 
monochromes,  suivant  une  sdquence  tdidchargde  de 
32  pas  maximum.  Le  signal  viddo  rdsultant  est 
gdndrd  avec  un  marquage  numdrique  de  chaque 
trame  et  des  synchronisations  video  reconstitudes. 

Fonctionnement 

La  carte  possede  huit  entrdes  viddo  couleur  RVB, 
externes  avec  protections  ou  internes  au  boitier. 

La  sdquence  de  multiplexage  est  de  32  pas 
maximum.  Chaque  pas  ddfinit  le  numdro  de  la 
source  a  transmettre,  la  durde  d'une  trame  ou  d'une 
image,  le  type  monochrome  ou  couleur  de  cette 
source.  Dans  le  cas  d'une  source  monochrome,  seui 
le  canal  vert  est  transmis  en  sortie. 


^11  12  13  ... 

^1  12  13  ... 

^11  12  13  ... 

4 

11  12  13  ... 

®11  12  13  ... 

Exemple  de  multiplexage  de  5  sources,  avec  Images  et  T ratnes, 
k  partir  de  la  trame  1 1  -  Sequence  I1,T2,  T3,I1,I4 

Le  multiplexage  temporel,  la  rdgdndration  des 
synchronisations  et  le  sdquencement  du  marquage 
sont  rdalisds  en  mode  nominal  a  partir  des  signaux 
de  synchronisation  systeme  gdndrds  par  le  BISE,  ou 
en  mode  secours  a  partir  de  signaux  extraits  du 
canal  vert  d'une  des  huit  sources.  Les  synchroni¬ 
sations  des  signaux  incidents  sont  supprimdes,  bien 
que  les  signaux  viddo  incidents  soient  normalement 
synchrones.  La  rdgdndration  des  synchronisations 
permet  d'envoyer  au  magndtoscope  un  signal 
totalement  ddpourvu  de  gigue. 

Le  signal  viddo  est  transmis  en  analogique  avec  une 
large  bande  passante,  sans  traitement  ni 
degradation. 

Les  donndes  utilisdes  pour  le  marquage  numdrique 
sont  celles  ndcessaires  a  la  restitution  de  mission, 
soit  le  numdro  d'identificateur  de  chaque  source 
viddo,  I'heure  systeme,  un  numdro  d'avion  et  un 
numdro  de  mission.  Elies  sont  programmdes  via  le 
bus  avion,  ainsi  que  la  sdquence  de  multiplexage. 

Ces  donndes  sont  insdrdes  dans  le  signal  viddo, 
dans  quelques  lignes  inutilisdes  en  ddbut  de  trame, 
suivant  le  principe  Tdidtexte.  Le  ddbit  numdrique 
ndcessaire,  de  40  bits  par  trame  est  faible.  Le 


\ 

/ 
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marquage  est  realise  par  huits  bits  de  donnees  sur 
les  lignes  1 0  a  1 5,  avec  des  bits  de  synchronisations 
en  debut  de  ligne  et  un  bit  de  parite  en  fin  de  ligne. 
La  frequence  bit  est  faible,  ce  qui  permet  une  grande 
robustesse  de  decodage  au  sol. 

Numero  de  Ligne 


Marquage  de  chaque  trame  video 


Toute  la  logique  de  commande  des  fonctions  de  la 
carte  est  integree  dans  un  composant  logique 
programmable  Xilinx  10  000  portes,  II  comprend 
I'interface  au  bus  numerique  interne  de  commande, 
les  memoires  de  sequence  et  de  donnees,  le 
sequenceur,  le  compteur  d'heure,  un  registre  a 
decalage  pour  le  marquage  des  donnees, 
I'asservissement  des  synchronisations  video. 

Une  evolution  permettrait  d'ajouter  au  marquage 
video  actuel  d'autres  donnees  provenant  des  bus 
avion  ou  emports,  k  des  debits  plus  eleves. 

3.2.  Evolution  vers  enregistrement  numerioue 

Le  systeme  actuel  d'enregistrement  magnetique  a  les 
inconvenients  de  I'analogique: 

-  rapport  signal/bruit, 

-  multitude  des  standards  de  codage  couleur, 

-  gigue  du  signal  enregistre  suivant  les  central ntes 
mecaniques, 

-  exclusivite  d'une  bande  magnetique  pour  un 
signal  video  et  un  signal  audio, 

-  mauvais  interfagage  avec  ordinateurs  pour 
restitution  numerique  des  images,  necessitant 
une  conversion, 

-  degradation  de  I'information  lors  de  copies. 

Un  enregistrement  magnetique  numerique  apporte 
des  solutions.  II  paraTt  interessant  de  faire  evoluer  le 
systeme  actuel  vers  un  enregistrement  numerique.  II 


est  possible  d'utiliser  un  enregistreur  de  la  classe  des 
30  a  40  Mbits/s,  moins  encombrant  et  moins  cher 
que  les  enregistreurs  hauts  debits  de  100  Mbits/s  et 
plus. 

Le  multiplexage  temporel  apporte  une  amelioration 
par  rapport  aux  systemes  precedents 
d'enregistrement  de  mission,  en  permettant 
d'enregistrer  plusieurs  sources  sur  une  seule 
cassette.  Un  enregistrement  numerique  doit 
permettre  d'aller  plus  loin,  en  fusionnant  les 
differents  supports  de  donnees  existant  actuellement 
en  une  cassette  unique.  Cette  cassette  sera  le 
support  unique  pour  plusieurs  signaux  videos 
integraux,  signaux  audio,  donnees  numeriques, 
evenements ... 

Les  signaux  video  necessitent  normalement  une 
bande  passante  importante,  1 60  Mbits/s  par  example 
en  4:2:2.  La  compression  video,  indispensable,  est 
une  technologie  qui  a  muri.  Les  solutions  sont  de 
plus  en  plus  integrees,  avec  un  coCit  en  baisse 
constante. 

Le  type  de  compression  (M-JPEG,  MPEG1 ,  MPEG2, 
ondelettes...)  et  le  taux  peuvent  etre  programmes  en 
fonction  de  I'interet  de  chaque  source  video  suivant 
la  phase  de  mission.  Certaines  sources  ont  un 
contenu  ci  variation  de  contenu  lent,  comma  les 
ecrans  de  symbologie.  Elies  peuvent  etre 
compresses  en  MPEG  avec  une  tres  bonne  qualite 
pour  un  debit  tres  faible  (2,5  a  3  Mbits/s). 

Grace  a  I'utilisation  d'un  support  unique  numerique, 
la  restitution  de  mission  sera  facilitee,  avec  des 
informations  accessibles  rapidement,  et  deja 
synchronisees. 


4.  RESTITUTION  DE  MISSION 

La  restitution  de  mission  est  une  activite 
operationnelle  complexe.  Nous  decrivons  un  sous- 
ensemble  permettant  la  restitution  des  signaux  video 
et  donnees  enregistrees  sur  une  cassette  video. 
Celui-ci  s'insere  dans  le  cadre  general  d'un  systeme 
de  restitution  de  mission,  permettant  I'analyse 
operationnelle.  Le  rejeu  video  peut  synchroniser  le 
rejeu  des  donnees  enregistrees  dans  I'avion  sur  les 
autres  media  extractibles. 

Le  materiel  utilise  est  du  materiel  faible  cout,  du 
commerce  (COTS). 
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4.1 .  Systeme  sol  de  demultiplexage  et 
EXTRACTION  DE  DONNEES 

La  cassette  video  une  fois  extraite  de  I'enregistreur 
embarque  de  I'avion  peut  etre  utilisee  au  sol  dans  un 
lecteur  non  durci  standard.  Le  signal  video  peut  §tre 
visualise  directement  sur  un  moniteur  video.  Lorsque 
la  video  comporte  un  multipexage  temporel  de 
plusieurs  sources,  les  images  sont  melangees  par 
I’oeil.  Une  telle  cassette  n'est  done  pas  exploitable 
sans  un  equipement  de  demultiplexage  temporel  des 
differentes  sources. 


sdlectionner  la  source  video  a  visualiser  parmi  celles 
existantes  dans  la  video  multiplexes  en  entree.  Les 
fonctions  principales  du  magnetoscope  peuvent  etre 
telecommandees. 

II  est  possible  de  demultiplexer  plusieurs  sources 
simultanement,  en  integrant  plusieurs  cartes  dans  le 
PC.  Le  demultiplexage  de  4  sources  a  ete  valide. 

Les  quatre  images  sont  envoyees  en  parallels  sur 
quatre  moniteur  video.  Une  nfXDsaique  en  quatre 
quarts  d'ecran  peut  egalement  ete  constituee  sur  un 
seui  moniteur. 


En  sortie  de  I'equipement  de  demultiplexage,  le 
mouvement  pergu  par  I'operateur  dans  le  signal 
video  demultiplexe  peut  etre  legerement  hache, 
dependant  de  la  sequence  de  multiplexage 
programmes  lors  de  t'enregistrement  de  mission  pour 
cette  source. 


Description  fonctionnelle 

Le  sous-ensemble  de  restitution  video  et  donnees 
developpe  pour  la  restitution  du  BISE  realise  les 
fonctions  suivantes: 


-  extraction  des  donnees  numeriques  marquees 
dans  chaque  trame,  avec  controls  de  coherence, 

-  demultiplexage  d'une  source  video  selection  nee 
par  I'operateur,  avec  memoire  d'image,  ou 
affichage  du  signal  video  d'entree  de  maniere 
transparente, 

-  affichage  des  donnees  extraites  par  incrustation 
dans  le  signal  video  de  sortie, 

-  interface  homme-machine  pour  affichage  des 
donnees  et  selection  de  la  source  a 
demultiplexer. 

L'equipement  de  demultiplexage  se  compose  d'une 
carle  video  du  commerce.  Cette  carte,  au  format 
ISA,  est  integree  dans  un  ordinateur  compatible  PC. 


VkJ^o  multiplex^e 
et  marquee 


CTO 


d^multiplex^e 


iCTO 


Cette  carte  comporte  une  entree  et  une  sortie  RVB, 
six  plans  memoire,  un  processeur  DSP.  L’entree  de 
la  carte  regoit  le  signal  d'un  magn^toscope  a  sortie 
RVB,  compatible  du  magnetoscope  embarque.  La 
sortie  de  la  carte  est  connectee  a  un  moniteur.  Le 
signal  demultiplexe  peut  egalement  etre  enregistr§ 
par  un  autre  magnetoscope. 

Un  logiciel  Windows  execute  par  le  PC  assure 
I'interface  homme-machine.  L'operateur  peut  ainsi 


Fonctionnement 

Les  differentes  fonctions  sont  assurees  en  temps  r6el 
par  le  processeur  DSP  de  la  carte.  Le  processeur  du 
PC  n'a  pas  besoin  d'etre  puissant,  et  est  disponible 
pour  le  logiciel  Windows.  Des  parametres  transmis 
par  ce  logiciel  Windows  en  fonction  du  choix  de 
I'operateur  indique  au  DSP  son  mode  de 
fonctionnement,  transparent  ou  demultiplexage,  et 
dans  ce  cas  le  numero  de  la  source  a  demultiplexer. 


source  a  visualiser 


numeriques  extraites 


Les  contraintes  mecaniques  subies  par  I'enregistreur 
embarque  entrainent  des  dephasages  importants  des 
synchronisations  video  lors  de  I'enregistrement  du 
signal.  La  carte  d'acquisition  s'asservit  sur  le  signal 
en  lecture  pour  compenser  cette  gigue. 

La  methode  retenue  pour  I'extraction  des  donnees 
est  originale,  et  entierement  numerique.  Elle  utilise 
les  ressources  de  la  carte  d'acquisition  video. 

A  chaque  trame  incidente,  les  ligne  10  a  1 5  sont 
numerisees  dans  une  zone  de  la  memoire  d'image. 
Pour  chaque  ligne,  le  DSP  realise  en  temps  reel  le 
seuillage  du  niveau  des  quelques  pixels 
correpondant  a  chaque  bit  numerique  marque,  apres 
calage  temporel  sur  les  premiers  bits  de 
synchronisation.  Les  6  octets  numeriques  transmis 
sont  ainsi  reconstitues  et  accumules  dans  un  buffer. 
Le  buffer  est  transmis  au  logiciel  Windows,  qui  peut 
I'afficher  et  le  Stocker  sur  disque. 

Des  la  ligne  16,  le  DSP  compare  le  numero  de 
source  transmis  dans  cette  trame  avec  celui 
selectionn6  par  I'operateur.  Si  le  numero  est 
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different,  le  DSP  attend  la  trame  suivante  sans  rien  ainsi  realiser  simultanement  I'analyse  de  missions 
faire.  La  memoire  de  visualisation  est  inchangee.  diff6rentes. 


Si  le  numero  de  cette  trame  correspond  a  celui 
selectionne  par  l'op6rateur,  le  DSP  declenche 
I'acquisition  du  contenu  video  de  la  trame  sur  les 
trois  plans  RVB  directement  dans  la  memoire  de 
visualisation. 

Le  signal  video  en  sortie  est  synchrone  du  signal 
d'entree.  Le  contenu  du  signal  de  sortie  correspond  ^ 
celui  de  la  memoire  d'image.  Lorsqu'il  est  configure 
en  mode  transparent,  ou  qu'une  video  sans 
marquage  numerique  lui  est  envoye,  le  signal  de 
sortie  est  identique  au  signal  d'entree. 


4.2.  Evolution  multi-appareils  multi-operateurs 

La  complexite  des  missions  va  en  augmentant. 
Plusieurs  appareils  sont  en  general  engages 
ensemble.  Une  restitution  de  mission  assurant  le 
rejeu  de  mission  d'un  seui  appareil  entraine  des 
limitations. 

Un  nouvel  ensemble  devrait  etre  developpe,  pour 
permettre  I'exploitation  synchronisee  des  donnees  de 
mission  de  plusieurs  appareils  en  patrouille, 
simultanement  par  plusieurs  operateurs 
independants. 

De  meme  que  I'enregistrement  de  mission  devrait 
evoluer  vers  un  enregistrement  numerique,  une 
restitution  video  numerique  presente  des  avantages. 

Description  fonctionnelle 

Le  sous-ensemble  de  restitution  video  permet  de  lire 
jusqu'a  quatre  cassettes  video  simultanement.  II 
pilote  les  quatre  magnetoscopes  de  maniere 
synchrone,  ce  qui  permet  de  visualiser  les  videos  de 
plusieurs  avions  synchronisees  sur  une  meme  heure. 
II  est  ainsi  possible  de  faire  une  analyse  de  mission 
d'une  patrouille  d'appareils. 

Cheque  cassette  video  peut  comporter  un  multi- 
plexage  temporal  de  sources  video  embarquees, 
jusqu'a  huit  sources.  Cheque  operateur  peut 
visualiser  par  demultiplexage  temporal  un  des  huit 
signaux  video  de  chacune  des  quatre  video  sur  son 
ecran  informatique,  ou  jusqu'a  quatre  video 
simultanement,  sous  forme  d'une  mosaique  de 
quatre  quarts.  Ces  quatre  signaux  sont  alors  choisis 
independemment  par  cheque  operateur  parmi  les  32 
signaux  capteurs  enregistres  dans  les  avions. 

Chaque  cassette  video  peut  egalement  etre  exploitee 
de  maniere  independante,  non  synchrone,  par  un  ou 
plusieurs  operateurs.  Plusieurs  operateurs  peuvent 


Fonctionnement 

Les  postes  operateurs  sont  connectes  au  sous- 
ensemble  de  restitution  video.  Ms  lui  envoient  leurs 
commandos  pour  le  pilotage  des  magnetoscopes, 
pour  le  rejeu  de  cassettes  en  mode  synchronise  ou 
independent. 


Le  sous-ensemble  video  asservi  les  magnetoscopes. 
Les  signaux  video  et  audio  de  chaque  magnetoscope 
sont  numerises.  Les  donnees  de  mission  marquees 
dans  chaque  trame  video  sont  extraites. 

Chaque  operateur  selectionne  independamment  des 
autres  un  h  quatre  signaux  video  qu'il  veut  restituter 
en  mosaique,  et  une  voie  audio. 

Cette  architecture  offre  de  multiples  avantages: 

-  les  signaux  issus  des  quatre  magnetoscopes  et 
selectionnes  sont  diffuses  sous  forme  numerique 
aux  operateurs, 

-  les  informations  sont  numerisees  une  seule  fois. 

II  n'y  a  pas  de  degradation  du  signal  due  a  des 
conversion  successives.  La  qualite  de  la  chaTne 
numerique  est  superieure  a  celle  des 
magnetoscopes  analogiques, 

-  le  moniteur  de  visualisation  de  la  station 
operateur  assure  une  visualisation  non 
entrelacee  a  haute  frequence,  ce  qui  assure  une 
meilleure  efficacite  et  une  moindre  fatigue 
oculaire  que  la  visualisation  directe  d'une  video 
entrelacee, 

-  revolution  pour  un  interfagage  avec  des 
enregistreurs  numeriques  haut  debit  est  facilitee, 
la  video  etant  deja  traitee  en  numerique. 
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5.  AUTRES  MODES  DE  RESTITUTION 

Alors  que  le  pilote  est  seui  pour  assurer  sa  mission, 
I'exploitation  des  donnees  est  realises  en  equips. 

Dans  certains  cas,  ces  equipes  souhaitent  recuperer 
les  donnees  immediatement.  Lorsqu'elle  est 
possible,  une  transmission  hertzienne  temps  reel  le 
permet. 

Dans  d'autres  cas,  le  pilote  peut  souhaiter  avoir  lui- 
meme  acces  a  certaines  donnees  pour  prendre  une 
decision  quant  au  deroulement  de  sa  mission.  Ces 
donnees  doivent  etre  stockee,  en  parallels  de 
I'enregistrement  de  mission,  dans  un  boitier 
embarque  avec  une  memoirs  consultable  sans  delai. 


5.1.  T RANSMISSION  TEMPS  REEL 

La  transmission  hertzienne  permet  une  exploitation 
de  mission  en  differs  immediat,  sans  attendre  le 
retour  des  appareils.  Les  donnees  peuvent  etre 
utilisees  pour  la  preparation  d'une  nouvelle  mission, 
qui  peut  ainsi  d6marrer  plus  tot. 

Differents  materiels  existent,  equipements  bord  et  sol 
(emetteur,  amplificateur,  antenne  fixe  ou  pointee, 
recepteur),  pour  une  transmission  numerique  ou 
analogique,  dans  differents  spectres  (400MHz,  2,5 
GHz,  15  GHz,  stale...). 


5.2.  Exploitation  dans  l'avion  en  rejeu  immediat 

Le  concept  d'un  equipement  d'acquisition  et 
restitution  video  immediate  est  en  cours  d'etude. 

Lors  du  deroulement  d'une  mission,  le  pilote  s'en 
tient,  autant  que  possible,  au  plan  de  vol  et  aux 
actions  prevus.  Lors  de  certaines  missions,  avec 
imperatif  de  destruction  par  exemple,  il  peut  etre 
necessaire  d'effectuer  un  deuxieme  passage. 

La  visualisation  en  differs  immediat  de 
I'enregistrement  de  la  video  d'un  capteur  (par 
exemple  pod  de  de  designation  laser  PDL),  avec 
fonctions  pause  /  avant  /  arriere,  facilite  revaluation 
des  dommages  et  permet  une  decision  locale  de 
fairs  ou  non  un  second  passage. 

Ce  type  de  fonction  est  egalement  extremement 
efficace  pour  I'entraTnement  des  pilotes. 

Le  boitier  d'acquisition  et  restitution  video  immediate 
numerise  un  signal  video  et  le  stocks  dans  une 
memoirs,  apres  compression  video  numerique. 
L'enregistrement  en  memoirs  est  realise  en  tambour, 


avec  une  autonomie  de  stockage  de  quelques 
minutes.  L'acquisition  peut  etre  stoppee  pour 
presen/er  le  contenu. 

L'utilisation  de  ce  boitier  est  independante  de 
I'enregistrement  de  mission,  qui  peut  enregistrer  le 
meme  signal  en  parallels.  Ainsi  les  dernieres 
minutes  ecoulees  peuvent  etre  revues  a  tout  instant, 
sans  perturber  I'enregistrement  de  mission,  ni 
conditionner  I'exploitation  qui  sera  faite  au  sol. 

Lors  de  la  demands  de  rejeu,  la  visualisation  du 
signal  est  immediate,  sans  cassette  magnetique  a 
rembobiner.  Les  fonctions  habituelles  de  pause, 
avance  avant/arriere  sont  disponibles.  Le  stockage 
numerique  permet  le  rejeu  des  images  de 
nombreuses  fois  avec  la  meme  qualite. 

Des  donnees  peuvent  etre  enregistrees 
simultanement,  et  restituees  incrustees  dans  I'image. 

Apres  exploitation  en  vol,  il  n'est  pas  necessaire  de 
conserver  les  images  en  memoirs.  L'exploitation 
complete  de  ce  signal  video  peut  etre  realises  au  sol 
a  partir  de  I'enregistrement  de  mission. 

L'architecture  du  boitier  fait  en  partie  appel  a  des 
composants  du  commerce  disponibles  en  gamme  de 
temperature  industrielle.  L'ensemble  est  durci  pour 
repondre  aux  contraintes  de  I'environnement 
embarque. 

II  se  compose  des  sous-ensembles  suivants: 

-  un  boitier  avec  fixations  et  interconnexions  de 
commands,  entree  video,  sortie  video, 

-  alimentation, 

-  carte  unite  centrals,  pour  gestion  des 
commandos,  des  donnees  bus  et  du  debit  video 
numerique, 

-  carte  d'interface  au  bus  de  donnees, 

-  carte  de  compression  /  decompression  video 
temps  reel,  avec  conversions  analogique  / 
numerique  et  inverse, 

-  cartes  memoirs,  de  capacite  configurable  suivant 
la  duree  d'enregistrement  necessaire. 

L'ensemble  se  contents  de  moins  d'un  litre  et  moins 
d'un  kilo. 

Le  boitier  peut  etre  configure  pour  un  signal  video 
625  lignes  (PAL)  ou  525  lignes  (NTSC).  La 
compression  est  realises  en  temps  reel,  trame  a 
trame,  suivant  la  norms  M/JPEG. 

Cette  fonction  pourrait  etre  incorporee  dans  un 
boitier  existant,  de  distribution  video  ou 
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d'enregistrement  de  mission,  pour  limiter  les 
interconnexions  et  les  redondances  de  type  boitier, 
alimentations... 

Lorsque  I'enregistrement  de  mission  embarque  sous 
forme  numerique  sera  une  realite,  le  support  pourra 
etre  de  la  memoire  en  remplacement  de  la  bande 
magnetique.  La  fonction  de  restitution  immediate 
pourra  alors  etre  integree  a  moindre  cout,  en  ajoutant 
simplement  une  decompression  temps  reel  et  une 
sortie  video,  et  en  utilisant  les  donnees  existantes 
dans  la  memoire  de  I'enregistreur  de  mission. 


6.  CONCLUSION 

SAGEM  S.A.  a  developpe  un  equipement  embarque 
dont  une  des  functions  est  le  multiplexage  temporel 
avec  marquage,  ainsi  qu'un  sous-ensemble  sol  qui 
realise  le  demultiplexage  video  et  I'extraction  des 
donnees  numeriques. 

Les  enregistreurs  magnetiques  doivent  etre  places 
dans  la  cabine  de  pilotage,  pour  la  tenue  mecanique 
et  I'accessibilite.  La  diminution  du  volume  n^cessaire 
dans  cette  zone  est  essentielle.  Le  multiplexage 
temporel  apporte  une  amelioration  par  rapport  aux 
systemes  precedents  d'enregistrement  de  mission. 


La  possibilite  d'enregistrer  jusqu'a  huit  sources  video 
en  les  gardant  exploitables,  la  reduction  globale  du 
cout  et  de  la  masse  sont  autant  d'avantages  decisifs 
de  cette  architecture. 

Les  evolutions  previsibles  de  cette  architecture  sont: 

-  une  exploitation  locale  avec  rejeu  immediat 
embarqu§,  en  video  numerique, 

-  un  enregistrement  de  mission  numerique  multi- 
donnees  sur  un  media  unique, 

-  une  restitution  de  mission  multi-appareils,  multi- 
operateurs,  multi-donnees,  en  vid6o  numerique, 

-  une  augmentation  de  I'integration  des  fonctions, 
dans  un  nombre  plus  faible  de  boTtiers 
embarques. 

L'augmentation  de  la  complexite  des  systemes  va  de 
pair  avec  l'augmentation  de  I'integration  des 
equipements.  Le  nombre  croissant  de  fonctions, 
dans  un  nombre  d'equipements  embarques  en 
baisse,  necessite  que  leur  developpement  sort 
conduit  par  des  societes  maitrisant  I'ensemble  des 
competences  fonctionnelles. 

SAGEM  S.A.  maitrise  la  chaTne  complete  de 
preparation,  enregistrement  et  restitution  de  mission. 


26-1 


A  GENERIC  ARCHITECTURE  FOR  CREW  ASSISTANT  SYSTEMS 


Pierre  J.M.  Urlings 
Rene  G.  Zuidgeest 

Air  Operations  Division 

Aeronautical  and  Maritime  Research  Laboratory 
Defence  Science  and  Technology  Organisation 
PO  Box  1500,  Salisbury  SA  5108 
Australia. 

National  Aerospace  Laboratory 
Anthony  Fokkerweg  2,  1029  CM  Amsterdam 
The  Netheiiaruls. 


1.  INTRODUCTION 

A  crew  assistant  is  an  on-botird  automated  system  that 
supports  an  aircraft  crew  in  perfonning  its  tasks. 
Aircraft  crews  are  currently  confronted  witli  numerous 
displays  and  complex  controls  in  their  cockpit.  An 
overwhelming  amount  of  multi-source  data  is  offered 
while  simultaneously  control  over  the  aircraft  and  its 
systems  has  to  be  maintained.  This  may  lead  to 
situations  of  high  workload  in  which  non-optimal 
decisions  are  made. 

Crew  assistant  systems  are  planned  to  reduce  this 
problem  and  hence  improve  efficiency  and  flight  safety. 
They  are  expected  to  rely  heavily  on  Advanced 
Infonnation  Processing  (AIP)  technologies  to  organise 
data  and  control  flow  in  such  a  way  tJiat  tlie  crew  is 
provided  with  concise  and  relevant  information.  At  the 
same  time  the  crew's  control  efforts  will  be 
considerably  reduced.  This  will  enable  the  crew  to 
concentrate  on  essentials  and  to  make  decisions  more 
effective. 

Several  developments  exist  in  tliis  area.  Pioneer 
programmes  are  the  US  “Pilot's  Associate"’",  the 
British  “Mission  Management  Aid”’^',  die  French 
“Copilote  Electronique"’'^'  and  the  Gennan  “Cockpit 
Assistant  System"’'*’.  The.se  programmes  go  by  different 
names  but  all  aim  at  die  automation  of  routine  tasks 
and  die  provision  of  effective  aids  to  the  crew  in 
problem  solving  and  task  management.  The 
architectures  developed  in  these  prognunrnes  have 
many  elements  in  common  but  suggest  a  more  generic 
architecture.  Another  common  element  of  tliese 
progrtunmes  is  tliat  they  consider  AIP  as  key 
technology  for  their  successful  implementation.  AIP 
provides  technologies  able  to  handle  the  complex 
interaction  between  crew,  crew  assistant,  aircraft 
systems  and  sensors. 


This  paper’  focu.ses  in  particular  on  the.se  two  aspects:  a 
generic  crew  assistant  architecture  and  the  application 
of  AIP  technology.  In  section  2  the  operational 
environment  is  described  in  which  a  crew  assistant  is  to 
be  embedded.  Section  3  introduces  a  generic  crew 
assistant  architecture  which  is  independent  of  any  type 
of  aircraft  or  operation.  Section  4  proposes  die 
application  of  AIP  in  general  and  of  multi-agent 
systems  in  pjadcular  as  a  key  technology  for  successful 
implementation  of  a  crew  assistant.  Throughout  the 
paper,  die  crew  assistant  is  illustrated  by  an  application 
of  a  single-pilot  military  aircraft,  but  die  concept  is  also 
relevant  to  multi-crew  or  civil  aircraft. 


2.  OPERATIONAL  ENVIRONMENT 

2.1.  Introduction  of  crew  assistant 

The  main  task  of  any  aircraft  crew  is  to  operate  its 
aircraft  to  attain  its  military  mission  or  civil  fiight 
objectives.  In  die  traditional  situation,  each  aircraft 
system  and  sensor  will  interface  direedy  widi  die  crew 
through  dedicated  controls  and  displays  in  die  cockpit. 
The  crew  has  to  interpret  multiple  displays  and  has  to 
operate  multiple  controls  simultaneously  in  order  to 
perfonn  die  funedons  that  are  related  to  its  main  task. 
In  die  non-assisted,  traditional  situation,  the  inter¬ 
pretation  of  all  sensor  infonnation  and  the  control  of  all 
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systems  remain  with  tlie  crew.  A  typical  example  is  an 
“oil  pressure  warning”  on  the  cockpit  system  panel 
which  may  indicate  an  oil  pressure  malfunction.  The 
crew  has  to  confum  tliis  hypotliesis  by  considering  oil 
pressures  at  a  variety  of  engine  power  settings  indicated 
in  its  checklist.  Once  this  hypothesis  is  confirmed,  tlie 
crew  has  to  adjust  tlie  engine  power  to  delay  further 
system  breakdown,  search  for  the  cause  of  the 
malfunction  and  meanwhile  replan  tlie  routing  to  a 
recovery  base  in  order  to  land  as  soon  as  practical. 

The  upward  arrows  in  the  traditional  situation  (left 
diagram  in  figure  1)  illustrate  tlie  information  flow 
from  sensors  to  the  displays,  downward  arrows 
illustrate  the  control  flow  to  tlie  systems.  For  reasons  of 
functional  consistency,  tlie  cockpit  elements  are  divided 
into  displays  (inputs  from  sensors  to  the  crew  only)  and 
conU'ols  (output  from  the  crew  to  systems  only).  The 
aircraft  elements  are  divided  into  sensors  (output  to 
displays  only)  and  systems  (input  from  controls  only). 

In  reality,  most  cockpit  and  aircraft  systems  will 
integrate  tlie.se  functional  elements. 


TRADITIONAL  CREW  ASSISTANT 

SITUATION  SITUATION 

Figure  1:  Crew  assistant  operational  environment 

The  right  diagnun  illustrates  the  situation  when  (a  part 
of)  a  crew  task  is  assigned  to  a  crew  assistant.  The 
original  task  is  then  split  into  a  (sub)function  delegated 
to  the  crew  assistant  and  a  (sub)task  tliat  remains  with 
tlie  crew.  Depending  on  how  much  of  tlie  original  task 
is  delegated  to  tlie  crew  assistant,  tliis  will  result  in  a 
change  in  the  amount  of  information  offered  to  tlie 
crew  and  in  a  change  in  tlie  amount  of  control  required 
from  tlie  erew.  In  die  “oil  pressure  warning”  example,  a 


crew  assistant  could  confirm  that  the  warning  is  indeed 
caused  by  an  oil  pressure  malfunction  and,  depending 
on  authorisation  by  the  crew,  the  crew  assistant  could 
execute  corrective  actions.  In  addition  the  crew 
assistant  could  propose  and  prepare  routing  to  the 
nearest  recovery  base. 

Figure  1  is  die  basis  for  further  discussion  in  diis 
paper.  The  external  elements  (crew,  tasks,  cockpit  and 
aircraft  elements)  will  be  described  in  diis  section  and 
the  crew  assistant  will  be  die  subject  of  the  next 
sections. 

2.2.  The  crew 

The  number  of  cockpit  crew  members  may  vary  from  a 
single  scat  military  fighter  to  3-4  members  of  a 
commercial  airliner  crew.  The  situation  of  a  single-seat 
fighter  aircraft  is  considered  to  place  the  most  severe 
requirements  on  a  crew  assistant.  The  situation  of  a 
multiple  member  aircrew  (military  transport  or  civil)  is 
less  demanding  but  may  have  additional  and  specific 
requirements.  The  commercial  need  in  civil  aviation  for 
reduction  of  crew  members,  has  already  led  to  the 
introduction  of  a  number  of  operational  crew  assistant 
realisations.  A  typical  example  is  die  Electronic 
CeiiU'alised  Aircraft  Monitoring  (ECAM)  system  on¬ 
board  the  Airbus-300  family  of  aircraft'^’. 

The  difference  between  a  military  and  a  civil 
application  will  provide  the  designers  of  crew  assistant 
system  with  an  interesting  design  dilemma.  It  is 
essential  for  military  operations,  and  especially  for 
tasks  that  are  related  to  tactics,  that  miliuu'y  pilots  are 
trained  to  be  "unpredictable".  This  implies  that  military 
crew  assistant  functions  which  require  modelling  or 
monitoring  of  pilot  behaviour  are  difficult  to  define.  In 
civil  aviation,  on  the  other  hand,  pilots  behave  more 
predictably  and  monitoring  pilots  behaviour  is  an 
attractive  area  for  crew  assistant  research  and 
applications''*'. 

2.3.  The  tasks 

The  aim  of  a  crew  assistant  is  to  provide  the  crew  widi 
an  improved  system  and  situation  awareness  and  to 
enable  the  crew  to  make  the  best  possible  decisions  in 
any  situation.  When  analysing  different  crew  tasks  to 
be  supported  by  a  crew  assistant,  it  is  attractive  to 
decompose  these  tasks  into  several  levels  of  hierarchy 
and  complexity.  The  hierarchy  between  these  levels  is 
that  the  crew  will  only  pay  full  attention  to  the  next 
level  once  all  tasks  allocated  with  the  previous  one  are 
handled  adequately.  Going  from  one  level  to  the  next 
level,  tlie  attention  span  of  tlie  crew  enlarges  and  tlie 
amount  of  infonnation  to  be  proces.sed  increases 
considerably.  The.se  tasks  levels  are: 
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•  the  aviate  level  which  includes  all  tasks  related  to 
handling  the  aircraft,  to  basic  Hying  and 
manoeuvring,  to  monitoring  system  health  and 
status,  and  to  encountering  system  malfunctions  and 
emergencies; 

•  the  navigate  level  which  includes  all  tasks  tliat  keep 
the  aircraft  on  the  intended  (navigational)  mission 
or  authorised  (air  traffic)  flight  plan; 

•  the  communicate  level  which  includes  the  tasks 
tliat  coordinate  will)  all  friendly  elements  that 
contribute  to  or  may  interfere  with  mission  or  flight 
intentions; 

•  the  operate  level  which  includes  the  tasks  tliat  deal 
witli  all  unfriendly  entities  that  directly  interact  or 
will  have  effect  on  the  successful  mission 
completion. 

The  workload  during  a  mission  or  flight  is  dependent 
on  the  amount  of  ta.sks  at  the  highe.st  level,  which  may 
be  very  different  for  a  military  mission  and  a  civil 
flight.  For  a  military  mission  the  tasks  at  tlie  "operate" 
level  (eg.  attack  phase)  represent  tlie  highest  workload 
and  will  occur  in  the  middle  of  tlie  mission.  For  a  civil 
flight  the  tasks  at  the  "communicate"  level,  during 
approach  and  landing  at  the  end  of  tlie  flight,  normally 
represent  the  flight  pha.se  witli  tlie  highest  workload. 

The  introduetion  of  operational  cTew  assistant  systems 
will  sumt  with  routine  tasks  at  tlie  “aviate”  level. 
Traditional  autopilots  (altitude/heading/attitude-hold) 
were  already  introduced  in  the  early-50s  and  can  be 
considered  first  crew  assistant  systems  Qiat  relate  to  tlie 
basic  Hying  tasks  of  the  “aviate”  level'*'.  Expansion  of 
autopilot  support  to  the  “navigate"  level  was  common 
on  most  civil  airliners  before  1980'^'.  The  research 
systems  Assistant  for  Single  Pilot  IFR  Operation 
(ASPIO,  1991)  and  Cockpit  Assistant  System  (CASSY, 
1995)  monitored  the  execution  of  a  civil  flight-plan  and 
apply  to  both  tlie  “navigate"  and  “communicate” 
level'*'.  Typical  military  examples  are  the  Joint  Tactical 
Infonnation  Distribution  System  (JTIDS,  first  delivered 
in  1993)  and  the  Multi-function  Information 
Distribution  System  (MIDS,  still  under  development 
and  designed  to  fit  smaller  fighter  aircraft).  These 
systems  provide  secure  voice  communication  and 
tactical  digital  infonnation  links,  and  apply  to  both  the 
“communicate”  and  “operate”  level'’'.  Most 
complicated  are  military  applications  that  are  designed 
to  support  tlie  ‘operate'  level.  Typical  examples  here 
are  the  .self  defence  mission  aids  in  development  for  the 
next  generation  fighters  which  aim  to  support 
electronic  warfare  tasks. 

2.4.  Cockpit  displays  and  controls 

When  adding  crew  assistant  to  support  different  crew 
tasks,  the  interaction  between  crew  and  crew  assistant 


depends  heavily  on  tlie  available  display  and  control 
interfaces  in  the  cockpit.  Contemporary  cockpits  reveal 
a  blend  of  display  and  control  technologies,  ranging 
from  conventional  electro-mechanical  dials  to  flat- 
panel  colour  displays  and  from  mechanical  switches  to 
voice-controlled  input  devices. 

By  far  the  greatest  majority  of  displays  use  vision 
although  audio  signals  are  used  to  provide  alerts  in 
danger  or  failure  situations.  Modem  displays  use  fast 
computer  processing  and  graphic  symbol  generators  to 
convert  sensor  information  into  digital  data  for 
presentation  on  eitlier  head-down,  head-up  or  helmet- 
mounted  displays.  Because  tJic.se  displays  can  be 
adapted  to  display  almost  any  type  of  information,  they 
became  Multi  Function  Displays  (MFD)  which  enables 
efficient  use  of  cockpit  space,  especially  in  a  front  panel 
location. 

Cockpits  incorporate  a  variety  of  mostly  manually 
operated  controls.  Recent  developments  might  allow 
voice  to  be  exploited  for  control  purposes  but 
recognition  rate,  response  time  and  input  error  rates  do 
not  match  tliose  of  manual  keyboard  entries.  Visual 
controls  and  in  particular  helmet  mounted  pointing 
sights  are  operational  in  state-of-llie-art  Russian  fighter 
aircraft.  The  field-of-view  for  target  designation  is 
much  wider  tlian  conventional  pointing  devices  and 
allows  full  exploitation  of  the  off-boresight  capability  of 
modem  guided  weapons.  Major  disadvantages  are  tlie 
weight  of  tlie  current  generation  sights  and  tlieir 
unreliability  at  high  g-load  factors. 

By  far  the  greatest  majority  of  controls  arc  still  manual 
and  tliey  can  be  located  anywhere  in  the  cockpit, 
provided  the  pilot  can  reach  them.  The  hands-on- 
tlirottle-and-stick  (HOT AS)  concept  that  is  pursued  in 
almost  all  military  fighters  collocates  important 
switches  with  tlie  flight  controls.  Cockpit  front  panels, 
quarters  panels  and  side  consoles  are  traditionally 
crowded  witli  singular  switches,  rocker  switches,  pu.sh 
buttons,  rotary  switches  and  joysticks.  Each  of  these 
was  originally  assigned  to  a  single  system  function. 
Multi-function  controls  are  possible  by  adding  arrays  of 
push  buttons  to  an  MFD.  A  variety  of  controls  are 
possible  by  displaying  their  active  input  function. 

Because  of  their  flexibility  and  capability  to  support 
complex  (display  and  coimol)  communication,  MFDs 
are  expected  to  play  a  major  role  in  crew  assisUuit 
applications.  Some  psychologists  and  human  factors 
experts  praise  MFD’s  capability  to  present  information 
and  to  reduce  pilot's  workload.  Otliers  expressed 
warnings  of  potential  infonnation  overload  eg.:  “tlie  F- 
1 8  cockpit  has  tliree  cathode-ray  tubes  and  a  head-up 
display;  tliere  are  675  acronyms  and  177  symbols 
which  can  appear  in  four  different  sizes  on  any  of  tlie 
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tlirec  cathode-ray  tubes;  there  arc  73  threat,  warning 
and  caution  indicators,  59  indicator  lights,  and  6 
warning  tones,  10  multi-function  switches  on  tlie 
tlrrottlc,  7  on  Uie  stick,  19  controls  on  the  panel 
undenieath  the  head-up  display,  and  20  controls  around 
tlie  periphery  of  each  of  tlie  three  cadtode-ray  tubes, 
each  of  which  has  a  multi-switch  capability"’*®'. 

2.5.  Aircraft  sensors  and  systems 

The  primary  task  of  any  aircraft  crew  is  to  operate  its 
aircraf  t  and  to  employ  its  sensors  and  systems  in  order 
to  attain  its  mission  (or  flight)  objectives.  When 
considering  a  crew  assistant  to  support  tlie  crew  in 
performing  tliis  task,  the  aircraft  sensors  and  systems 
tliat  play  a  role  can  be  divided  according  to  tlie 
different  task  levels  of  section  2.3. 

Sensors  and  systems  to  aviate.  The  aviate  task  is  to 
keep  the  aircraft  airborne  and  includes  basic  flying  and 
system  health  monitoring.  Main  sensors  and  systems 
are  the  aircraft  attitude  (pitch-,  roll-,  and  yaw-angle) 
sensors  and  tlie  flight  controls,  closely  linked  witli 
engine  perfonnance  sensors  and  control.  Current  status 
of  automation  already  provides  basic  autopilot  functions 
and  engine  perfonnance  optimisation  during  different 
flight  phases  (take-off,  climb,  crui.se).  Additional 
systems  included  in  the  aviate  task  are  flaps,  slats,  dive 
brakes,  drag  chute,  landing  gears,  aircraft  support 
systems  (electrical  power,  fuel,  hydraulics)  and  life 
support  systems  (oxygen,  etc).  These  systems  are  not 
expected  to  play  a  role  in  crew  assistant  applications 
because  they  are  already  self-contained  and  mostly  fully 
automated. 

Sensors  and  systems  to  na  vigate.  Navigation  comprises 
3 -dimensional  routing  and  timing  of  an  aircraft  such 
that  it  reaches  pre-defined  positions  at  pre-defined 
times.  This  task  can  only  be  executed  with  sufficient 
knowledge  of  present  position  and  existing  restrictions 
as  contained  in  air  traffic  control  procedures  and  flight 
plan.  Military  operations  are  supplemented  with  a 
variety  of  time  and  position  dependent  restrictions. 
Various  state-of-tlie-art  automation  supports  navigation 
along  a  horizontal  and  vertical  flight  path  (eg. 
autopilots  for  VOR  interceptions  or  ILS  landings),  or 
are  controlled  by  a  Flight  Management  System  (FMS). 

It  is  expected  that,  by  die  year  2000,  satellite  based 
navigation  (GPS)  will  be  the  prime  navigation  aid  for 
die  en-route,  terminal,  non-precision  and  precision 
approach  phases  of  flight.  Present  ground  based 
navigation  aids  will  be  gradually  phased  out  and  GPS- 
INS  embedded  systems  will  provide  a  uniform  concept 
with  unprecedented  accuracy  for  automated  navigadon 
support  during  die  entire  flight. 


GPS  is  also  a  conierstone  technology  of  the  free  flight 
concept  which  envisaged  diat  air  traffic  control  systems 
would  allow  individual  aircraft  to  utilise  their  own 
direct  routing  and  air  traffic  separation.  Both 
navigation  and  air  traffic  control  are  candidate  areas  for 
crew  assistant  developmeiiLs. 

Sensors  and  systems  to  communicate.  Communication 
includes  two-way  verbal  communication  between 
aircraft  crew  and  other  entities,  systems  for 
identification  (IFF/SIF),  and  tacdcal  target  and  data 
links.  The  most  suitable  area  for  crew  assistant  support 
is  verbal  communication,  especially  during  flight 
phases  widi  a  high  workload  (approaches  under  air 
traffic  control)  or  during  mi.ssion  phases  that  are 
cridcal  for  successful  mission  accomplishment  (ground 
controlled  intercepts  or  ground  directed  attacks). 

Sensors  and  systems  to  operate.  The  operate  task  refers 
to  milit;u-y  roles.  Aircraft  sensors  and  systems  diat 
support  diese  roles  vary  much  dependent  on  the  specific 
demands  from  their  operational  environment:  eg.  air- 
to-air  defence,  air-to-ground  attack,  defence 
suppression,  airbonie  surveillance  or  airbonic 
commtuid  and  control.  Consequently,  candidate  tasks 
for  crew  assistant  support  are  manifold  and  range  from 
target  acquisition  and  weapon  management  to  situation 
assessment  and  self  defence. 


3.  FUNCTIONAL  ARCHITECTURE 

The  previous  section  defined  the  operational 
environment  of  a  crew  assistant  and  described  its 
complexity.  A  crew  assistant  will  help  the  crew  operate 
in  this  environment  and  will  even  hide  some  of  the 
complexity  from  the  crew.  This  section  presents  the 
functional  architecture  of  a  crew  assistant  and  describes 
how  tlie  crew  assistant  will  interface  widi  this 
operational  environment. 

The  functional  architecture  (see  figure  2)  is  based  on  a 
modular,  horizontal  and  vertical,  decomposition.  The 
crew  assistant  can  be  seen  as  a  collection  of  relatively 
independent  functions  tliat  assist  the  crew  in  different 
tasks  and  hence  will  require  different  capabilities.  The 
crew  assistant  can  also  be  seen  as  a  data  processing  unit 
tliat  processes  low-level  data  in  several  stages  from 
aircraft  sensors  up  to  easy-to-assess  information  to  be 
displayed  to  the  crew. 

Coordination  and  interfacing  between  the  crew 
assistant  and  tlie  crew,  and  between  tlie  crew  assistant 
and  aircrtifl  cockpit  elements,  will  be  allocated  to  four 
additional  interface  management  modules. 
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3.1.  Functions 

The  crew  assistant  functions  directly  support  crew 
(sub)tasks.  Ideally  single  crew  assistant  functions  may 
correspond  with  single  crew  tasks.  It  is  also  possible 
tliat  tlie  crew  assistant  includes  modules  of  multiple 
functions  supporting  strongly  related  (sub)tasks.  This 
separation  into  functional  modules  will  aim  at  a 
maximum  internal  coherence  within  one  functional 
module  and  at  a  minimum  interaction  between  different 
modules.  The  modules  are  at  the  same  hierarchical 
level  which  results  in  the  first  (horizontal) 
decomposition  of  the  architecture  (see  figure  2). 

Typical  military  tasks  to  be  supported  by  a  crew 
assistant  were  identified  during  EUCLID  RTF  6.5. 
Interviews  were  conducted  wiUi  33  pilots  from  air 
forces  of  the  participating  nations,  flying  the  F-16, 
MRCA  and  AM/X.  Reference  missions  (air-to-air  and 
air-to-ground)  were  defined.  Key  criteria  for  task ' 
identification  were  their  operational  relevance,  their 
impact  on  pilot  workload  and  mission  effectiveness  and 
the  expected  applicability  of  AIP  technologies'"’.  The 
following  typical  tasks  were  identified: 

System  management:  addresses  monitoring  of  nonnal 
system  perfonnance  (and  in  particular  engine  perfor¬ 
mance),  trend  analysis,  and  reporting  of  information  on 
system  status. 

Malfunction  handling:  relates  to  analysis  of  anomalies, 
to  presentation  of  appropriate  warnings,  to  (checklist) 
assistance  in  countering  malfunctions,  and  (when 
authorised)  to  automatic  execution  of  corrective  actions. 

Mission/fUght  planning:  includes  the  capability  to 
monitor  mission/flight  progress,  to  evaluate  the  impact 
of  environmental  entiues  (eg.  adverse  weather  and 
enemy  threats)  on  this  plan  and,  if  needed,  to  assist  in 
or  to  perform  an  automatic  (re)planning. 

Situation  awareness:  relates  to  the  capability  to 
combine  and  interpret  all  available  environmental  data 
in  order  to  derive  an  easy  to  assess  situation  picture  of 
tliis  environment;  situation  awareness  may  be  limited  to 
navigational  information  but,  for  military  applications, 
includes  all  relevant  strategic  and  tactical  infonnation. 

Self  defence:  addresses  mtinagemenl  of  self  protection 
systems,  assessment  of  sensor  infonnation,  selection  of 
available  countenneasure  options,  and  (automatic) 
execution  of  tlie  selected  tactics. 

3.2.  Data  processing  levels 

For  each  crew  assistant  function,  die  basic  flow  of  data 
is  from  die  aircraft  sensors  to  die  cockpit  displays.  It  is 


the  goal  of  a  crew  assistant  to  direct  diis  flow  by 
processing  aircraft  sensor  data  into  infonnation  for 
display.  The  main  objective  is  to  provide  the  crew  with 
concise  and  relevant  infonnation.  In  this  process,  a 
number  of  steps  can  be  distinguished,  each  representing 
a  processing  level  at  which  data  are  combined  with 
infonnation,  knowledge  and  procedures  and  interpreted 
into  infonnation  for  a  next  step.  Four  processing  levels 
are  distinguished  (see  figure  2):  collection,  assessment, 
decision  and  presentation. 


Figure  2:  Functional  architecture  of  crew  assistant 

At  the  collection  level,  data  are  collected  and  prepared 

for  furdier  assessment.  This  includes: 

•  the  collection  of  data  from  sensors  and  other  input 
devices  on-board  the  aircraft, 

•  the  transfonnation  of  tliese  data  into  a  fonnat  that 
can  be  read  by  the  assessment  level, 

•  the  execution  of  complex  operations  in  which  data 
from  different  sensors  are  integrated  into  a  standard 
data  fonnat  (eg.  by  sensor  datti  fusion). 
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•  tlie  preliminary  filtering  of  data  by  rejecting 
irrelevant  data  or  by  giving  priority  to  data  that  are 
urgently  needed  by  higher  processing  levels. 

At  the  assessment  level,  tlie  collected  data  are  assessed 
on  nonnal  or  abnormal  properties.  This  includes: 

•  the  comparison  of  data  from  tlie  collection  level, 
mutually  or  by  comparison  with  reference  data  (eg. 
threshold  values), 

•  the  execution  of  complex  processing,  eg.  the 
analysis  of  system  trends  by  examining  a  range  of 
chronological  data  values  and  tlie  prediction  of 
values  in  order  to  anticipate  future  problems, 

•  the  assessment  of  the  aircraft  environment  on  the 
basis  of  sensor  data. 

At  the  decision  level,  it  is  decided  what  has  to  be 
presented  to  tlie  crew  on  the  btisis  of  inputs  from  tlie 
assessment  level  and  possibly  provide  autonomous 
control.  This  includes: 

•  the  filtering  of  data  from  tlie  assessment  level  in 
order  to  prevent  saturation  of  the  crew's  cognitive 
resources, 

•  die  generation  of  advice  on  handling  abnormal 
situations, 

•  if  authori.sed,  die  execution  of  autonomous  action, 
i.e.  control  die  aircraft  systems. 

Finally,  at  the  presentation  level,  it  is  decided  how  die 
infonnation  from  the  decision  level  is  presented  to  the 
crew.  This  includes: 

•  an  assessment  of  die  available  cockpit  display 
resources  and  crew  preferences, 

•  die  presentation  of  information  in  such  a  way  diat 
the  crew  is  directly  cued  and  able  to  process  die 
information  efficiendy  and  effectively. 

Each  processing  level  has  a  characteristic  combination 
of  type  of  data,  information,  knowledge  and  operations. 
These  levels  communicate  with  each  odier 
hierarchically  and  result  in  the  second  (vertical) 
decomposition  of  die  architecture  (see  figure  2).  Inputs 
from  a  higher  level  are  intended  for  control  or  request 
for  information.  The  lower  level  is  obliged  to  act 
according  to  this  input.  Conversely,  inputs  from  lower 
levels  are  intended  to  be  infonnation  only.  A  higher 
level  is  free  to  process  diis  input.  The  decision  level  is 
modelled  to  be  die  only  level  that  receives  external 
coordination  from  die  crew  and  it  is  the  only  level  that 
provides  control  to  aircraft  systems.  Crew  coordination 
includes  preferences  for  display  presentation  and 
authorisation  to  die  crew  assistant  to  control  aircraft 
systems. 


The  different  levels  of  data  processing  widiin  the  crew 
assistant  show  similarity  widi  die  hierarchical  model 
and  processing  levels  proposed  forC^I  data  fusion'^^l 
The  main  difference  is  that  the  data  fu.sion  process 
specifically  supports  situation  and  threat  assessment 
widiin  a  C’l  application  while  die  crew  assistant 
process  will  support  a  variety  of  crew  tasks,  including 
situation  and  direat  assessment. 

3.3.  Interface  management 

Crew  assistant  externally  interfaces  with  displays  and 
controls  in  die  cockpit  and  widi  sensors  and  systems 
on-board  die  aircraft.  The  crew  assistant  functional 
architecture  adds  capabilities  to  organise  die 
corresponding  data,  information  and  control  flows. 
These  capabilities  are  organised  in  four  interface 
management  modules  (see  figure  2):  coordination, 
control,  data  and  presentation  management.  Different 
aspects  of  interface  management  will  be  discussed  in 
die  next  sections. 

3.3.1.  Coordination  management 

Crew  assistant  authority.  By  delegating  a  task  to  die 
crew  assistant,  die  crew  inevitably  has  to  specify  die 
nature  of  its  interaction  and  die  authorisation  for 
presentation  and  control.  This  delegated  authority  can 
be  expressed  in  standiud  levels  of  automation  (eg. 
stiuid-by,  manual,  semi-automatic  and  automatic).  Full 
automation  is  outside  the  scope  of  die  crew  assistant 
and  in  die  "automadc"  mode  die  crew  assistant  should 
at  least  infonn  die  crew  on  the  status  of  its  activities 
and  should  instantaneously  accept  a  reset  by  die  crew  at 
any  time.  The  crew  should  have  a  correct  and  complete 
understanding  of  die  functioning  of  the  crew  assistant 
in  all  modes,  in  order  to  allow  a  smooth  transition 
between  different  modes  and  to  maintain  consistency 
with  manual  (non  crew  assistant)  operations.  The  crew 
remains  in  die  loop  and  may  regain  control  at  any  time. 

Coordination  between  functions.  When  several  tasks 
are  delegated  to  crew  assistant,  interactions  will  take 
place  which  require  coordination  between  the 
corresponding  functional  modules.  This  includes: 

•  translation  and  decomposition  of  the  request  for 
assistance  by  the  crew  into  die  activation  of  all 
needed  functions  widiin  die  crew  assistant; 

•  prioritisation  between  crew  assistant  functions  when 
simultaneous  execution  of  crew  assistant  functions 
results  in  conflicts  that  arc  related  to  the  crew 
(limited  cognitive  capabilities),  to  die  aircraft 
(limited  available  cockpit  displays  or  supporting 
sensors)  or  to  odier  resources  (computer  memory, 
processing  power  or  diroughput  capability); 
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•  cooperation  between  crew  assistant  functions  when 
some  functions  need  specific  results  from  another; 
tliis  control  (or  request  for  data)  is  pcrfonned  at  the 
decision  level  though  the  actual  exchange  of  data 
may  remain  at  die  assessment  level. 

3.3.2.  Control  management 

Overruling  by  the  crew.  For  each  function  that  is 
delegated  to  the  crew  assistant,  die  crew  shall  be  able  to 
overrule  the  crew  assistant.  Overruling  may  cause 
sensors  and  systems  to  receive  control  inputs  from  bodi 
die  crew  and  crew  assistant  which  may  be  connicting. 
This  conflict  is  prevented  within  the  de.sign  of  the  crew 
assistant  by  routing  all  control  inputs  through  a  control 
management  module.  Note  diat  overruling  of  system 
control  is  basically  different  from  de-selecting  crew 
assistant. 

Conflicting  system  control.  A  conflict  in  system 
control  exists  when  the  same  aircraft  system  is 
employed  simultaneously  both  by  die  crew  and  crew 
assistant  while  each  performs  a  different  task.  This 
occurs  when  eg.  the  crew  assistant  perforais  a  mission 
planning  function  and  directs  a  radar  in  its  ground 
mapping  mode  while  simultaneously  the  crew  selects 
diat  radar  to  operate  in  an  air-to-air  mode.  Control 
management  prioritises  and  solves  such  conflicts  and, 
when  required,  informs  the  crew  and  requests 
additional  guidance. 

When  multiple  functions  are  assigned  to  the  crew 
assistant,  the.se  may  also  conflict  in  controlling  the 
same  systems.  This  may  occur  when  eg.  (short  tenn) 
self  defence  functions  and  (long  term)  mission  planning 
functions  simultaneously  request  die  same  sensor  to 
provide  informadon.  Solving  these  conflicts  has  to 
match  the  way  the  crew  would  solve  them. 

Crew  requested  input.  Occasionally,  the  crew  assistant 
may  not  be  able  to  collect  all  data  required  to  perform  a 
function,  eg.  because  a  sensor  is  malfunctioning  or 
because  diere  is  no  sensor  available.  Such  data  can  be 
obtained  by  requesting  the  crew  to  provide  them. 
Loading  mission  data  via  a  crew  inserted  data  cartridge 
is  part  of  diis  capability. 

Sensor  management.  When  data  collection  requires 
activation  or  redirection  of  a  sensor,  diis  control  is 
subject  to  crew  audiorisation  and  does  not  differ  from 
control  of  other  systems.  Control  management, 
therefore,  should  include  sensor  management. 

3.3.3.  Data  management 

Importing  sensor  data.  Data  management  is 
responsible  for  importing  and  filtering  all  sensor  data 


as  required  by  the  active  crew  assisduit  functions.  One 
function  might  require  data  from  multiple  sensors 
while  other  functions  might  require  data  from  the  stunc 
sensor.  DaUt  management  is  responsible  for  correlation 
of  filtered  data  widi  the  crew  assistant  internal  data.  It 
is  expected  tliat  data  management  and  data  collection 
will  be  closely  integrated  in  die  system  design  of  a  crew 
assistant. 

Sensor  data  fusion.  Data  management  is  closely  related 
to  sensor  data  fusion,  but  the  overall  sensor  data  fusion 
problem  should  be  resolved  outside  the  crew  assistant. 
The  functional  architecture  assumes  responsibility  for 
correct  data  to  remain  with  each  sensor  individually 
and  the  responsibility  for  correctly  fused  data  widi  the 
involved  sensors  collectively. 

3.3.4.  Presentation  management 

Limited  display  resources.  The  crew  assistant  will  be 
operational  in  a  cockpit  environment  that  is  expected  to 
rely  heavily  upon  MFD  technology.  This  implies  diat 
conflicting  requirements  in  die  presenkidon  of 
infonnation  are  likely  to  emerge  when  multiple  crew 
assistant  functions  simulUmeously  require  access  to  die 
same  display.  Solving  diese  conflicts  has  to  match  the 
way  the  crew  would  solve  diem.  Remaining  conflicts 
should  be  prioritized  and,  when  required,  additional 
guidance  should  be  requested  from  die  crew. 

The  crew  assistant  may  also  be  in  conflict  widi  a  sensor 
not  involved  with  crew  assistant  if  both  require  die 
same  display  in  die  cockpit.  Since  such  a  conflict 
emerges  by  the  introduction  of  a  crew  assistant,  it 
should  be  solved  by  the  crew  assistant.  The  conflict 
could  also  be  solved  by  displays  that  are  dedicated  only 
to  the  crew  assistant. 


4.  ADVANCED  INFORMATION  PROCESSING 

The  crew  assistant  architecture  presented  shows  a 
moduku"  approach  in  which  various  functional  elements 
can  be  marked  as  knowledge  intensive.  It  also  shows 
that  crew  assistant  interactions  are  complex  and  that 
diese  interactions  should  remain  transparent  to  die 
crew  at  all  times.  Advanced  Informadon  Processing 
(AIP)  provides  technologies  able  to  hiuidle  this 
complexity  and  support  a  sophisdeated  man-machine 
interaction  by  minimising  the  cognitive  gap  between 
man  and  machine.  Candidate  AIP  technologies  are: 

•  knowledge-based  systems, 

•  natural  language  and  speech  understanding, 

•  perception,  including  advanced  sensor  data 
processing  and  fusion. 
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•  planning,  eg.  for  in-llight  mis.sion  planning, 

•  learning  to  improve  crew  assistant  capabilities, 

•  distributed  problem  solving. 

This  section  will  focus  on  how  to  realise  a  crew 
assistant  system  architecture.  The  features  of  AIP 
technologies  tltat  are  required  to  provide  a  firm  basis 
for  a  crew  assistant  system  architecture  are  reviewed 
first.  It  is  further  argued  tliat  distributed  problem 
solving,  and  in  particular  multi-agent  systems,  arc 
proper  AIP  technologies  for  the  crew  assistant  overall 
system  architecture  while  otlier  technologies  might  be 
applicable  to  specific  elements  within  tliis  system 
architecture. 

4.1.  Requirements  for  AIP  applications 

The  AIP  technologies  tliat  will  be  applied  to  develop 
die  crew  assistant  functional  architecture  into  a  system 
architecture  should  have  features  that  satisfy  die 
following  design  requirements: 

Modularity.  The  crew  assistant  shall  be  based  on 
technologies  that  allow  logical  decomposition  of  the 
system  into  smaller  components  (modules)  widi  well- 
defined  interfaces.  Modularity  facilitates  development, 
enables  future  upgrades  and  reduces  life-cycle  costs  by 
improved  maintenance. 

Real-time  performance.  The  crew  assistant  shall  have 
guaranteed  response  times  in  a  highly  dynamic 
environment.  It  may  be  better  to  provide  an  acceptable 
response  in  time  dian  to  provide  a  response  that  is  best, 
but  too  late.  This  can  be  extended  widi  the  requirement 
for  a  response  being  not  too  complex.  Although  a 
complex  re.sponse  is  in  time,  its  contents  might  be 
difficult  to  understand.  Real-dme  perfonnance  is  a 
cridcal  factor  in  crew  acceptance. 

Reliability.  The  crew  assistant  shall  have  built-in 
hardware  and  software  elements  diat  are  designed  to 
reduce  tlie  risk  of  a  complete  system  failure.  The 
applied  technologies  should  allow  for  a  graceful 
perfonnance  degradation  in  case  of  failure. 

Integration.  The  crew  assistant  includes  many  diverse 
functions  needing  different  implementation  methods 
and  techniques.  The  technology  used  should  support 
integration  widi  conventional  as  well  as  advanced 
mediodologies  preserving  modularity. 

System  engineering.  The  crew  assistant  shall  be 
developed  and  maintained  by  a  well-defined  and 
widely-accepted  system  engineering  mediodology.  The 
technology  used  should  support  such  a  methodology  in 
order  to  reduce  development  and  life-cycle  costs. 


Maturity.  The  crew  assistant  shall  be  based  on  mature 
and  proven  implementation  technologies.  This  is 
exprcs.sed  by  die  availability  of  tools,  successful 
prototypes  and  operational  applications. 

4.2  Distributed  I’robiem  Solving 

An  emerging  candidate  technology  for  realisation  of  the 
crew  assistant  system  architecture  is  Distributed 
Problem  Solving  (DPS)**^'.  This  technology  provides  a 
natural  transidon  from  die  crew  assistant  functional 
architecture  to  a  system  architecture  where  die  inherent 
distribution  and  modularity  of  functions  is  preserved  in 
die  functionally-distributed  problem  solving  modules. 

DPS  technology  considers  two  main  approaches: 
distributed  knowledge  sources  (often  referred  to  as 
blackboard  systems)  and  multi-agent  systems.  Both 
consist  of  multiple  agents  but  they  differ  in  structure  at 
global  architecture  level  and  at  agent  level.  A  multi¬ 
agent  system  normally  consists  of  heterogeneous  agents 
diat  have  a  range  of  expertise  or  functionality  (eg.  a 
complete  knowledge-based  system  performing  a 
specific  function  such  as  mission  planning  or 
malfunction  handling).  These  agents  have  die  potential 
to  function  stand-alone  but  are  also  able  to  cooperate 
widi  other  agents'*"*'. 

In  a  blackboard  system,  the  agents  are  knowledge 
sources  interacting  dirough  a  shared  memory:  the 
blackboard' *'‘''.  Here,  only  knowledge  is  disfiibuted,  but 
data,  infonnation  and  coiiuol  are  cenU'al  as  compared 
to  multi-agent  systems.  A  common  (shared)  data 
structure  for  a  complex  crew  assistant  system  widi 
heterogeneous  knowledge,  data  and  functions  is  not 
likely  to  be  obtained.  A  cenual  blackboard  system 
control  will  also  be  a  bottleneck  for  real-Ume 
perfonnance.  Therefore  the  application  of  a  blackboard 
system  seems  to  be  limited  to  single  crew  assistant 
functions  only.  In  fact,  the  blackboard  system  concept 
provides  a  natural  way  to  design  and  implement  the 
layered,  vertical,  processing  structure  of  a  crew 
assistant  function.  Blackboard  system  technology  can 
be  suitable  for  specific  crew  assistant  functions  such  as 
aircraft  system  status  diagnosis'**',  threat  assessment' *’*, 
data  fusion  and  object  identification'**',  and  overall 
crew  assistant  system  management'***'. 

4.3.  Multi-agent  system  technology 

While  blackboard  systems  might  be  suitable  at  the  crew 
assistiuit  function  level,  multi-agent  systems  provide 
the  technology  and  basis  for  die  overall  system 
mchitccturc.  This  architecture  will  be  based  on  multiple 
cooperative  agents,  where  each  agent  implements  a 
crew  assistant  function.  Each  agent  has  its  own  local 
data,  infonnadon,  knowledge,  operations  and  control 
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that  are  relevant  for  tlic  problem  or  task  domain  of  the 
function.  This  encapsulation  increases  modularity  and 
reduces  complexity. 

The  agent  capabilities  and  tlieir  potential  to  cooperate 
and  achieve  goals  beyond  the  capabilities  of  a  single 
agent  detennine  the  total  system  functionality. 
Cooperation  in  particular  is  the  key  to  a  sound  crew 
assistant  system  architecture  that  is  compliant  witli 
basic  requirements  such  as  modularity,  reliability,  real¬ 
time  performance  and  comprehensible,  predictable 
system  behaviour.  It  directly  addresses  tlie  key  problem 
in  tlie  crew  assistant  as  shown  in  the  functional 
architecture:  how  to  manage  interaction  between  crew, 
crew  assistant  functions  and  aircraft  systems,  all  being 
agents  on  tlieir  own.  Important  features  for  optimal 
cooperation  and  coordination  in  die  crew  assistant 
provided  by  multi-agent  system  technology  are: 

Organisation.  A  well-defined  system  organisation  in 
order  to  oversee  the  complexity  and  to  enhance  real¬ 
time  perfonnance.  A  relatively  fixed  community-like 
organisation  (following  a  set  of  rules  of  behaviour  to 
avoid  system  conflicts  or  hannful  behaviour)  is 
preferred  above  a  market-like  organisation  (which  has 
dynamic  negotiation  as  its  key  strategy  and  assumes 
well-defined  task  hierarchies  tliat  can  be  dynamically 
decomposed  into  nearly  independent  sub-tasks,  which 
is  unlikely  to  be  the  case  with  the  crew  assistant)  or  a 
centralised  organisation  (where  a  single  coordinator 
will  be  a  bottleneck). 

Distribution.  Knowledge,  responsibilities,  control  and 
capabilities  can  be  distributed  and  localised  in  crew 
assistant  agents  (tlirough  specialisation,  dependency 
reduction,  and  increased  local  capabilities)  so  that 
coordination  decisions  are  part  of  local  decisions  rather 
than  a  separate  layer  (coordinator)  above  local  problem 
solving. 

Planning.  Planning  (eg  the  plan-goal  graph  in  the 
Pilot's  Associate'*’’)  will  synchronise  individual  agent's 
behaviour  and  will  resolve  confiicts  before  or  during 
actual  execution. 

Contextual  Awareness.  Other  methods  to  improve 
coordination  are  to  develop  and  increase  common 
contextual  awareness  between  multi-agents  so  that  tlicy 
can  m;ike  better  and  less  conlhcling  decisions.  A 
typical  example  is  a  function  for  situation  assessment 
that  maintains  a  world  model  tliat  is  accessible  by  all 
otlier  functions.  Coordination  will  be  improved  by  a 
common  awareness  on  what,  how  and  when  to 
communicate  in  which  relevance,  timelinc.ss,  and 
completeness  of  infonnation  are  key  properties’’**'. 
Common  knowledge  will  also  avoid  confiicts  in  tlie  use 
of  limited  resources. 


For  reasons  of  modularity,  real-time  perfonnance  and 
reliability,  it  is  argued  that  coordination  and  interface 
management  not  to  be  left  to  a  single  agent,  but  to 
distribute  it  and  make  it  an  integral  part  of  each  agent's 
cooperation  capabilities.  This  means  that  in  a  multi¬ 
agent  crew  assistant  system  architecture,  tliere  is 
unlikely  to  be  a  central  coordination  and  interface 
management  as  is  present  in  the  functional 
architecture. 

Present  stale  of  the  art  DPS  and  multi-agent  system 
technologies  are  expected  to  satisfy  the  requirements 
for  a  successful  implementation  of  a  crew  assistant, 
especially  in  respect  to:  modularity,  real-time 
performance,  reliability,  integration  and  system 
engineering’^*’.  Example  crew  assistant  systems  that 
already  apply  DPS  technology  arc: 

•  Cockpit  Information  Management  prototype 
system  that  uses  a  blackboard  architecture  as 
basis’^^’. 

•  Pilot's  Associate  which  adopts  a  distributed 
blackboard  architecture  in  order  to  structure  tlie 
system  as  a  heterogeneous,  loosely  coupled  system 
in  which  individual  agents  are  not  restricted  to  a 
particular  development  environment  or  software 
approach'*’’.  Communication  between  modules  was 
centrally  coordinated  by  a  blackboard-based  agent 
called  tlie  Mission  Manager,  but  tliis  centralised 
approach  has  been  abandoned  in  subsequent  system 
design  for  complexity  and  performance  reasons  and 
is  being  decentralised  and  distributed  among  tlie 
agents. 

•  A  prototype  application'^'^’  of  an  expert  system  that 
manages  a  .set  of  cooperating  expert  systems.  It 
provides  interaction  management  towards  tlie 
multiple  expert  systems  as  well  as  interaction 
management  towards  the  crew,  so  that  the 
complexity  of  the  multi-expert  system  is  hidden 
from  the  crew. 

•  Copilote  Electronique  which  is  based  on  a  fiexible 
heterogeneous  implementation  paradigm'"’’  which  is 
evaluated  on  perfonnance  witli  the  simulation  tool 
SAHARA”"’. 

Maturity  of  multi-agent  systems  is  rcfiected  by  a 
growing  list  of  development  tools  which  in  most  cases 
have  integrated  a  blackboard  system  technology.  For 
crew-assistant  applications  it  is  recommended  that 
specific  arrangements  arc  made  to  ensure: 

•  a  relatively  fixed  agent  organisation  in  order  to 
map  each  crew  assistant  function  on  a  specific 
agent,  to  reduce  control  complexity  and  non¬ 
determinism  (which  guarantees  a  consistent  and 
predictable  behaviour  towards  tlie  crew)  and  to 
provide  predictable  load  bahuicing  of  tlie  limited 
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computer  resources  in  regard  to  data  transfer 
bandwidth  and  processing  power; 

•  a  predictable  conflict  resolution  where  the  agents 
opt  for  die  same  solutions  (eg.  selection  of  aircraft 
system  modes)  and  die  same  use  of  resources  (eg. 
choice  of  cockpit  interfaces)  to  address  consistently 
the  limited  cognitive  capabilides  of  die  crew. 

5.  CONCLUSIONS 

A  crew  assistant  is  an  on-board  automated  system 
which  will  support  die  crew  in  perfonning  its  task.  It 
will  enhance  efficiency  and  flight  safety  in  a 
demanding,  complex  operational  environment.  This  is 
achieved  by  assigning  (a  part  of)  the  crew  task  to  the 
crew  assistant.  Depending  on  how  much  of  the  original 
task  is  delegated,  the  amount  of  infonnation  offered  to 
the  crew  and  the  amount  of  control  required  of  the  crew 
will  be  significantly  reduced.  This  will  enable  the  crew 
to  concentrate  on  essendals  and  make  more  effective 
decisions. 

This  paper  presents  a  generic  funcdonal  architecture  of 
the  crew  assistant  based  on  die  operational  environment 
in  which  it  will  operate.  This  functional  architecture  is 
modular  in  several  dimensions  and  idenufies: 

•  various  separated  crew  assistant  funcdonal  modules, 

•  different  levels  of  data  processing  within  each 
functional  module, 

•  management  modules  which  interface  die  crew 
assistant  with  crew  and  aircraft. 

For  crew  assistant  development,  it  is  recommended  to 
identify  early  in  the  design  process  die  single  or 
multiple  functions  supporting  single  or  strongly  related 
crew  tasks.  This  will  result  in  functional  modules  with 
a  maximum  of  internal  coherence  and  a  minimum  of 
interaction.  Future  modifications  will  also  benefit  from 
this  modularity.  When  eg.  a  cockpit  display  has  to  be 
replaced,  only  the  presentation  module  diat  addresses 
that  display  has  to  be  adapted.  The  other  modules 
remain  unaffected. 

The  functional  architecture  includes  various  elements 
that  are  knowledge  intensive.  Advanced  Infonnation 
Processing  provides  technologies  able  to  handle  the 
complexity  of  the  operational  environment  and  to 
support  sophisticated  man-machine  interacdon. 

This  paper  proposes  Distributed  Problem  Solving 
technology  in  particular  as  a  key  technology  to  develop 
the  functional  architecture  into  a  system  architecture. 
The  suggestion  is  to  let  a  multi-agent  system  fonn  die 
backbone  of  die  architecture  diat  includes  coordination 
aspects  and  to  apply  blackboard  system  technology  to 


local  function-dependent  problem  solving.  With  respect 
to  real-time  operation,  the  multi-agent  system 
architecture  will  be  able  to  make  a  U'ade-off  between 
agent  communicadon  and  computation,  and  the  agent's 
blackboard  system  is  particularly  suited  to  making 
problem-dependent  trade-offs  between  quality  and 
responsiveness. 

Maturity  of  DPS  development  tools  and  existing 
realisations  lead  one  to  expect  that  next  generation 
crew  assistant  applications  will  adopt  widely  die 
distributed  problem  solving  and  multi-agent 
technology.  Specific  arrangements  are  required  to 
satisfy  specific  needs  widiin  a  crew  assistant 
application. 
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1  SUMMARY 

Due  to  increasing  demands  put  on  crews  of  military  aircraft, 
effective  cockpit  systems  will  be  required  in  order  to  reduce 
workload  and  to  improve  crew  performance.  This  paper 
presents  various  approaches  to  crew  assistance  in  tactital 
flight  missions.  The  underlying  tasks  are  tactical  decision 
making,  low-level  flight  planning  and  flight  guidance.  The 
integration  of  the  Tactical  Situation  System  as  part  of  a 
knowledge  based  crew  assistant  and  a  flight  guidance  display 
system  incorporating  sensor  and  synthetic  vision  components 
offer  a  promising  solution  to  improve  the  situational 
awareness  of  the  crew.  Respective  prototypes  have  been 
successfully  tested  and  evaluated  in  a  simulated  environment 
as  well  as  by  flight  trials. 


2  INTRODUCTION 

2.1  Human  factors  in  crew  assistance 

Human  operators  might  be  overtaxed  due  to  the  various  tasks 
resulting  from  military  air  transport  missions  in  hostile 
enviromnents.  Guiding  the  aircraft  through  adverse  weather 
conditions  in  ground  proximity  puts  further  demands  on  crew 
performance.  [5]  Most  accidents  can  be  at  least  partly 
attributed  to  human  erroneous  actions  due  to  increasing  crew 
workload.  [7]  Human-centered  automation  [2]  offers  a 
promising  approach  to  the  solution  of  the  obvious  problems  of 
the  enabling  technology  oriented  flight  deck  automation. 

The  main  scope  of  present  programmes  on  on-board  pilot 
assistance  is  the  enhancement  of  the  crew’s  situational 
awareness.  In  order  to  improve  the  situation  assessment 
capabilities  it  must  be  ensured  that  the  attention  of  the 
cockpit  crew  is  guided  towards  the  objectively  most  urgent 
task  of  the  situation  and  if  necessary  the  workload  is  reduced 
to  a  normal  degree  which  can  be  handled  by  the  crew.  [7] 
Under  pressure  of  time  the  pilot’s  infonnation  processing 
performance  might  be  shifted  to  a  skill-based  level.  [9] 
Tasks,  such  as  planning  and  decision  making,  performed  on  a 
rule/knowledge-based  level  under  normal  operating 
conditions  can  no  longer  be  performed  in  situations  with  high 
workloads.  Even  different  tasks  yield  specific  pilot’s 
strategies  of  information  gathering  and  processing.  [13,  15] 
Therefore,  situation  dependent  assistance  has  to  be  provided 
in  order  to  cover  all  aspects  which  are  also  to  be  considered 
as  situational  aspects  by  the  cockpit  crew.  [7] 


The  next  section  deals  with  approaches  of  how  to  address 
human  operators  at  different  performance  levels  by  using 
appropriate  assisting  functions. 


2.2  Merging  approaches  for  crew  assistance 

Various  approaches  for  crew  assistant  systems  emphasize 
different  aspects  concerning  situations,  resulting  tasks,  and 
respective  human  performance.  The  main  scope  of  the 
activities  is  to  merge  the  following  approaches  for  crew 
assistance: 

One  approach  to  effective  crew  assistance  in  order  to  meet 
the  requirements  of  human-centered  design  is  to  incorporate 
the  capability  of  situation  assessment.  The  situation 
assessment  has  to  be  perfomed  by  the  cockpit  crew 
continuously  during  flight.  In  parallel  the  same  assessment  is 
done  by  the  functions  of  the  machine  part  of  the  man-machine 
system.  [7]  The  development  of  the  Cockpit  Assistant  System 
CASSY  and  respective  flight  tests  [8]  covers  this  aspect  in 
the  field  of  civil  air  transport  mission  scenarios.  In  military 
environments  additional  aspects  related  to  low-level  flight 
planning  and  guidance  and  tactical  constraints  arise. 

Another  approach  is  to  consider  visual  perception  aspects  of 
human  performance  in  crew  assistance.  Enhanced  and 
synthetic  vision  systems  are  the  today’s  choice  in  order  to 
improve  the  crew’s  situation  awareness  in  the  context  of  low- 
level  flight  guidance.  While  classical  systems  such  as  radar 
based  terrain  following  systems  or  flight  director  systems 
avoid  or  at  least  decrease  the  involvement  of  the  pilot, 
enhanced/synthetic  vision  systems  keep  the  pilot  active  in  the 
flight  guidance  loop.  Thereby,  the  principles  of  the  cognitive 
approach  to  flight  deck  automation  can  be  met.  [2,  15] 
Scientific  research  studies  offer  relevant  design  principles.  [1, 
3,4,  10,  12, 17] 

This  paper  presents  a  synthesis  of  the  above  two  approaches 
to  a  Tactical  Situation  System  representing  the  military 
operations  related  modules  of  the  assistant  system  extended 
by  the  addition  of  an  Enhanced  Flight  Guidance  System  to 
assist  the  pilot  in  manual  visually  guided  flight  at  low 
altitudes  and  in  adverse  weather  conditions. 


3  KNOWLEDGE-BASED  CREW  ASSISTANCE 

The  Crew  Assistant  Military  Aircraft  (CAMA)  is  an  on-board 
knowledge-based  expert  system  for  efficient  crew  assistance 
in  military  aircraft  missions  developed  in  cooperation  with 
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the  University  of  the  German  Anned  Forces  Munich  -  which 
is  responsible  for  the  overall  design  [8,  16]  -  Deutsche 

Aerospace  (DASA)  and  the  German  Aerospace  Research 
Establishment  (DLR).  It  is  designed  in  a  first  stage  to 
improve  the  situational  awareness  of  the  crew  in  air  transport 
missions.  Therefore,  it  assists  the  crew  in  planning  and 
decision-making  tasks  through  all  flight  phases. 

The  following  two  sections  deal  with  general  aspects  of  the 
CAMA  system  concept  and  the  military  operations  related 
components. 


3.1  Functional  levels  of  the  crew  assistant 

Figure  1  shows  the  core  modules  of  the  Crew  Assistant 
Military  Aircraft  and  its  integration  into  the  flight  guidance 
loop.  The  electronic  crew  member  gathers  information  from 
the  crew  via  the  monitoring  of  command  and  control  actions. 
The  aircraft  and  external  data  sources  (ATC,  Nav,  weather 
etc.)  are  connected  to  the  system  by  appropriate  sensors  or 
communication  media. 


Figure  1:  Crew  Assistant  Military  Aircraft  architecture 


The  Central  Situation  Representation  is  a  dynamic  object- 
oriented  representation  of  situation  relevant  data.  It  contains 
all  situation  related  (dynamic)  and  domain  related  (static) 
knowledge.  The  Crew-Interface  is  the  audio-visual 
communication  layer  between  the  crew  assistant  and  the 
crew.  It  selects  and  coordinates  information  to  be  shown  on  a 
2D  map  display  or  issued  via  a  speech  synthesizer.  The  latter 
provides  system  control  through  speech  recognition.  The 
Planning  layer  generates  a  complete  flight  mission  plan.  [8] 
In  the  Situation  Interpretation  layer  this  flight  plan  is  used  as 
reference  for  the  crew  model.  Here,  the  expected  crew  action 
patterns  are  elaborated  and  aspects  of  the  external  situation 
(tactical  elements,  terrain  etc.)  are  evaluated.  The  modules  in 
the  Situation  Assessment  layer  are  supposed  to  detect 
conflicts  in  the  expected  succession  of  the  flight  and  to 
recognize  the  crew’s  intents  and  errors.  In  the  case  of  a  pilot 


error,  a  warning  or  hint  is  given  to  the  crew  to  correct  the 
error.  In  order  to  cope  with  the  temporary  discrepancy  of  crew 
intent,  CAMA  tries  to  figure  out  the  intention,  modifies  the 
flight  plan  accordingly,  and  elaborates  the  consistent 
expected  behaviour  again.  [8]  The  structure  of  CAMA 
mirrors  the  general  design  philosophy  not  to  allocate 
functions  on  the  machine  side  or  the  crew  side  alone  but  to 
both  sides  in  parallel.  [7]  Thus,  assisting  functions  can  be 
provided  on  all  human  performance  levels. 


3.2  Tactical  situation  related  assistance 

Deviations  from  the  mission  plan  might  be  induced  by  the 
crew  while  reacting  to  a  suddenly  changing  mission  scenario. 
Therefore,  the  assistant  system  has  to  cope  with  the  tactical 
situation  in  order  to  predict  related  crew  behaviour  patterns, 
recognize  respective  crew  intents  and  errors  and  detect 
conflicts  in  mission  plan  execution.  The  Tactical  Situation 
System  as  part  of  the  crew  assistance  system  consists  of  the 
following  components: 

•  Tactical  Situation  Interpreter 

•  Low-altitude  Flight  Planner 

•  Tactical  Situation  Display 

•  Enhanced  Flight  Guidance  Display 

In  order  to  incorporate  tactical  elements  in  the  planning  and 
decision-making  considerations,  the  Tactical  Situation 
Interpreter  is  integrated  in  the  situation  interpretation  layer  of 
CAMA.  On  the  basis  of  a  full-scale  threat  and  terrain 
evaluation,  a  low-level  flight  plan  is  calculated  by  the  Low- 
altitude  Flight  Planner.  The  Low-altitude  Flight  Planner  is  a 
submodule  in  the  CAMA  planning  layer.  The  resulting  low- 
level  flight  plan  can  be  monitored  according  to  the  IFR 
(Instrument  Flight  Rules)  flight  plan  supervision.  A  detailed 
flight  trajectory  is  displayed  to  the  pilot  on  the  Enhanced 
Flight  Guidance  Display  when  assistance  is  needed  on  a  skill- 
based  level.  The  Tactical  Situation  Display  offers  a  crew 
interface  to  the  Tactical  Situation  System.  It  is  an  interactive 
map  display  depicting  terrain  elevation  and  cultural  feature 
data,  tactical  and  threat  information  as  well  as  a  variety  of 
navigational  elements. 

The  following  chapter  provides  a  closer  view  to  the  functions 
and  architecture  of  the  Tactical  Situation  System. 


4  THE  TACTICAL  SITUATION  SYSTEM 

The  Tactical  Situation  System  [11]  is  a  software  prototype 
system  developed  in  parallel  to  the  CAMA  activities.  It 
covers  the  military  operations  related  aspects  of  crew 
assistance  in  order  to  demonstrate  advanced  mission 
management  technologies  and  support  the  pre-development 
phase  of  future  air  transport/weapon  systems.  The  aim  of  the 
investigations  is  to  create  flexible  system  prototypes  for 
cockpit  avionics  in  order  to  elaborate  user  requirements  and 
evaluate  respective  prototypes  with  operational  personnel 
under  human-machine-interaction  considerations. 

Based  upon  the  experience  gained  in  the  development  of  the 
crew  assistant  the  Tactical  Situation  System  consists  of  four 
main  modules  as  described  as  follows. 


4.1  The  Tactical  Situation  Interpreter 

The  Tactical  Situation  Interpreter  is  a  knowledge-based 
module  in  the  context  of  the  situation  interpretation  layer  as 
referring  to  the  CAMA  architecture.  Its  main  contribution  is 
the  computation  of  a  threat  map.  The  calculation  is  based 


27-3 


upon  digital  terrain  elevation  data  (DIED)  [19]  and  the 
threat’s  models.  Particular  objects  from  a  given  list  of 
tactical  elements  are  regarded  as  threats  such  as  surface-to-air 
missiles  (SAM)  or  radar  sites.  A  threat  model  contains  the 
parameters 

•  maximum  range, 

•  operationability, 

•  efficiency  along  range  and 

•  respective  models  for  threat  area  overlapping. 

Figure  2  shows  the  principle  steps  of  the  algorithm  for  the 
threat  value  calculation. 


Figure  2:  Threat  map  calculation 

Due  to  the  characteristics  of  the  threat’s  radar  systems  and 
respective  radar  shadows  resulting  from  the  terrain  structure, 
the  altitude  above  ground  up  to  which  an  aircraft  is  not 
detectable  by  the  hostile  radar  beams  can  be  derived  from  the 
digital  terrain  elevation  database  (DTED).  Given  a  certain 
test  altitude  a  threat  value  of  zero  can  be  assumed  below 
these  radar  beams.  Above  the  threat  value  is  calculated  as  a 
function  of  the  individual  model  parameter.  The  threat  values 
are  calculated  for  ten  discrete  altitudes  above  ground  level 
(test  altitudes  every  50  meters  in  the  z-axis)  and  for  each 
terrain  elevation  grid  point  (longitude/latitude  coordinates). 
Area  overlapping  of  threats  is  taken  into  consideration  by 
probability  calculus. 


Figure  3:  Threat  map  with  SAMs’  range  circles 


Figure  3  depicts  a  typical  result  of  a  threat  map  calculation. 
The  actual  threat  is  limited  by  the  drawn  range  circle  and  by 
the  radar  shadow  of  a  hill  on  the  left. 


4.2  The  Low-altitude  Flight  Planner 

The  aim  of  the  Low-altitude  Flight  Plaimer  is  the  calculation 
of  a  three-dimensional  route  between  mission-given 
waypoints  with  a  maximum  probability  of  survival  in  a 
hostile  environment.  This  is  achieved  by  avoiding  threatened 
areas  if  possible,  minimizing  the  exposure  to  unknown 
threats  and  keeping  clear  of  the  terrain.  Therefore,  the 
mission  constraints,  the  tactical  elements  and  the  resulting 
threat  map,  the  terrain  elevation  data  and  the  aircraft 
performance  data  are  taken  into  consideration.  The  output  of 
the  plaimer  is  a  detailed  trajectory  and  a  waypointyflightleg- 
oriented  representation.  Figure  4  shows  the  architecture 
concept  of  the  planner. 


Figure  4:  Low-altitude  Flight  Planner  architecture 


The  system  consists  out  of  three  functional  submodules: 

1 .  The  danger  analysis  incorporates  the  threat  map 
calculation  as  described  in  section  4.1.  Additionally,  the 
visibility  at  each  point  is  calculated  without  assuming  any 
particular  threats.  The  algorithm  issues  lower  danger 
values  on  the  side  of  valleys  than  in  the  center.  This 
behaviour  reflects  pilot’s  low-level  flying  preferences. 
Finally,  the  danger  analysis  utilizes  the  calculation  of  a 
ground  collision  probability,  which  is  particularly  high  in 
rough  terrain.  This  feature  leads  to  generally  higher  flight 
altitudes  in  the  absence  of  threats.  An  overall  danger 
value  is  calculated  for  each  terrain  grid  point  and  stored 
as  a  danger  model  in  an  array. 

2.  The  moding/control  checks  the  flight  status  and 
assembles  the  target  point  and  the  planning  area  for  the 
optimization  according  to  the  mission  constraints.  The 
optimization  provides  an  array  of  optimal  directions  to  the 
target  point.  As  long  as  a  replanning  does  not  imply  a 
new  target  point  another  optimization  run  is  not  required. 
This  means  that  the  algorithm  offers  an  optimal  path  from 
each  point  in  the  planning  area  to  the  desired  target  point. 
This  calculation  is  done  for  each  waypoint.  The  numerical 
optimization  is  based  on  dynamic  programming  [6]  and 
uses  a  large  number  of  calculation  steps  for  global 
optimization.  In  order  to  achieve  an  operational  system 
for  in-flight  replanning  which  provides  a  low-level  flight 
plan  in  reasonable  computing  time,  some  heuristical 
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considerations  have  to  be  applied.  The  reduction  of  grid 
points  to  be  taken  into  account  is  done  by  ignoring  grid 
points  beyond  an  ellipse  around  the  actual  flight  leg. 

3.  The  path  selection  depends  on  the  current  planning  mode 
(initial  planning  or  replaiming).  It  constructs  a  terrain 
grid  based  flight  path  from  a  given  start  point, 
respectively  present  aircraft  position  to  the  target  point. 
The  output  assembly  functions  trajectory  synthesis  and 
plan  analysis  form  the  Low-altitude  Flight  Planner 
output. 

•  In  order  to  be  monitored  by  a  pilot  model  based 
assistant  system,  the  representation  of  the  detailed 
trajectory  has  to  be  reduced  to  a  waypoint  based  low 
altitude  flight  plan,  which  represents  the  general 
considerations  to  be  followed  in  the  human  plarming 
of  low  level  missions  i.e.  threat  avoidance,  terrain 
masking,  timing  etc.  The  reduction  is  done  through  a 
low  pass  filtering  operation  of  the  optimal  trajectory. 

•  Additionally,  the  low-level  flight  plan  is  given  by  a 
detailed  trajectory  representation.  Thereby,  an 
assisting  function  on  the  skill-based  human 
performance  level  can  be  provided.  During  normal 
operation  the  pilot  selects  the  trajectory  to  fly  by  the 
consideration  of  relevant  influences.  The  execution 
can  be  monitored  by  the  crew  assistant.  In  situations 
of  increased  workload  it  is  possible  that  the  pilot  is  no 
longer  able  to  select  a  safe  and  efficient  flight  path,  hr 
this  case  the  display  of  the  automatically  generated 
trajectory  is  a  helpful  tool. 


Figure  5;  Low-altitude  flight  plan  on  elevation  map 

Figure  5  shows  a  typical  planning  result  between  two 
waypoints  considering  only  the  terrain  elevation.  The  result  is 
an  optimal  trajectory  minimizing  the  cost  function  of 
weighted  terrain  elevation  data  and  local  threat  values 
integrated  over  the  complete  flight  path. 


4.3  The  Tactical  Situation  Display 

The  Tactical  Situation  Display  provides  the  primary  crew 
interface  to  the  Tactical  Situation  System.  Basically,  it  is  an 
interactive  electronic  moving  map  display  for  navigational 
and  operational  purposes.  The  aim  of  the  interface  is  the 
improvement  of  the  pilot’s  situational  awareness.  Situational 
awareness  is  guaranteed  if  the  pilot  has  all  relevant 
information  for  the  present  flight  situation  at  his  disposal  and 
is  therefore  able  to  cope  with  the  posed  tasks.  The  actual 
information  needed  for  task  performance  is  highly  influenced 
by  the  task  itself  [13,  15].  Obviously,  the  map  information 
required  for  radio  navigation  is  completely  different  to  the 
information  in  the  context  of  visual  navigation.  Typically,  the 
differences  are  more  subtle.  The  Tactical  Situation  Display  is 


primarily  designed  in  order  to  cope  with  the  advancing 
knowledge  on  human  'information  processing.  Therefore,  it 
allows  the  composition  of  the  display  contents  from  a  vector 
oriented  database.  The  display  utilizes  digital  terrain 
elevation  data  (DTED)  and  digital  feature  analysis  data 
(DFAD)  [19]  in  order  to  create  a  topographical  map  in  any 
required  scale  and  orientation  (north/heading  up).  The 
various  feature  classes  can  be  displayed  selectively  providing 
a  very  efficient  decluttering  of  the  screen  contents.  Radio 
navigation  symbology  can  be  added  by  visualizing  Jeppesen 
Navigation  Data.  Military  operations  related  aspects  are 
covered  by  the  incorporation  of  tactical  symbols  (as  indicated 
in  Figure  3).  The  threat  map  display  can  be  activated  for  the 
different  above  ground  levels  or  be  slaved  to  the  aircraft’s 
present  altitude.  The  ground  track  of  the  low-altitude  flight 
plan  is  indicated  as  in  Figure  5. 


Figure  6  tries  to  give  a  general  impression  of  the  appearance 
of  the  Tactical  Situation  Display.  It  shows  the  display 
depicting  the  feature  data  and  the  threat  map  in  a  1:100,000 
heading-up  representation.  The  system  is  designed  as  a  head- 
down  display. 

Several  other  display  elements  are  included  in  order  to 
emphasize  the  correlation  between  the  Tactical  Situation 
Display  and  the  Enhanced  Flight  Guidance  Display  (see 
section  4.4)  with  respect  to  human  performance  oriented 
system  design.  Details  are  given  in  section  4.5. 

Additionally,  the  system  provides  an  interface  to  the  Low- 
altitude  Flight  Planner.  It  allows  the  pilot  to  enter  waypoints 
interactively  by  marking  them  on  the  map.  The  control  is 
done  by  use  of  a  cockpit  trackball  for  the  analogue  inputs  and 
pushbuttons  for  the  discrete  inputs. 


4.4  The  Enhanced  Flight  Guidance  Display 

Several  scientific  research  studies  [3,  4, 10,  15]  start  from  the 
assiunption  that  the  pilot’s  information  gathering  from  the 
out-the-window  view  is  critical  for  flight  guidance  in  low- 
level  flight  and  landing  tasks.  Flying  under  restricted  visual 
conditions  requires  additional  technical  means  to  assist  the 
pilot  performing  the  task.  Classical  flight  guidance  systems 
for  instrument  flight,  such  as  flight  director  display  or  ILS 
indicator,  give  only  very  reduced  information  gathered  by 
simple  sensors  from  the  real-world  situation.  Therefore,  the 
pilot’s  situational  awareness  might  be  fairly  low  and  the  pilot 
still  has  to  learn  adapted  flying  skills  instead  of  just  utilizing 
his  natural  and  extremely  powerful  skills  of  flying  in  a  three- 
dimensional  visual  world. 


27-5 


The  Enhanced  Flight  Guidance  Display  is  a  promising 
approach  to  the  solution  of  the  problems  with  poor  visibility 
low-level  flight.  It  comprises  an  imaging  sensor  (e.g.  FLIR, 
irunWR,  LL-TV)  and  the  superimposition  of  the  sensor  image 
with  a  computer-generated  three-dimensional  cockpit  view. 
The  incorporation  of  sensory  data  is  essential  for  the  benefit 
of  the  system.  Due  to  incomplete  or  incorrect  databases,  the 
pilot  cannot  only  rely  on  the  synthetic  image  components. 
Inaccuracies  of  the  navigation  system  yield  another  basic 
problem  for  just  synthetic  vision  systems. 

Thus,  the  Enanced  Flight  Guidance  Display  is  not  a  synthetic 
vision  system.  It  does  not  try  to  produce  a  most  realistic 
representation  of  the  out-the-window  view  as  used  in  visual 
systems  of  training  flight  simulators  but  is  instead  a  display 
carrying  situation  and  task  relevant  information. 

Therefore,  the  Enhanced  Flight  Guidance  Display  consists 
out  of  the  following  visual  components: 

•  The  non-conformal  flight  guidance  overlay  is  a  standard 
head-up  display  symbology  with  speed,  altitude  (MSL, 
AGE),  heading,  vertical  velocity  readouts  and  a  bank  and 
sideslip  indicator. 

•  The  conformal  flight  guidance  symbology  incorporates  an 
attitude  display  and  artificial  horizon.  The  flight  guidance 
tunnel  visualizes  the  three-dimensional  flight  trajectory. 
A  velocity  vector  and  flight  path  predictor  depict  dynamic 
aircraft  movement  information.  [18]  The  predictor  symbol 
consists  of  three  U-shaped  brackets  (for  the  1,  2  and  3 
second  prediction)  in  order  to  fit  into  the  flight  guidance 
tunnel.  The  symbology  is  denoted  as  tunnel  dock  (see 
Figure  8,  center). 

•  The  conformal  terrain  contour  symbology  is  a 
perspective  depiction  of  the  digital  terrain  elevation 
database.  Air  traffic  obstacles  exceeding  a  minimum 
height  taken  from  the  digital  feature  analysis  database  are 
shown  as  well  as  airfields. 

•  The  sensor  image  is  added  to  the  synthetic  parts  of  the 
display  in  order  to  cope  with  incomplete  databases. 


Figure  7:  Synthetic  symbology  of  Enhanced  Flight 
Guidance  Display 


Figure  7  tries  to  depict  the  synthetic  parts  of  the  display.  The 
format  shown  is  typical  for  a  head-down  application,  because 
of  the  coloured  terrain  surface.  The  colouring  is  switchable 
between: 

•  an  absolute  elevation  coding  colour  key  as  used  in  the 
map  display  and 

•  a  collision  warning  colour  code,  which  assigns  red  colour 
to  the  terrain  higher  than  the  ownship  altitude. 


The  same  colour  codes  can  be  independently  assigned  to  a 
perpendicular  east/north-fixed  terrain  grid.  Using  only  the 
terrain  grid  without  the  surface  colouring  produces  a  more 
head-up  display  type  symbology  which  is  applicable  in 
combination  with  the  sensor  image  (see  Figure  8). 


Figure  8:  Flight  guidance  symbology  for  sensor  image 
combination 


The  software  prototype  of  the  Enhanced  Flight  Guidance 
Display  is  designed  in  order  to  allow  rapid  changes  of 
formats  and  functions  to  easily  meet  user  and  design 
requirements. 


4.5  Correlation  between  2D  and  3D  display 

Due  to  the  tasks  arising  out  of  the  operational  mission 
context,  it  can  be  expected  that  there  will  be  a  large  workload 
connected  with  a  2D  map  display.  This  might  lead  to  a  loss  of 
situational  awareness  concerning  the  aircraft’s  attitude  and 
terrain  proximity.  Therefore,  the  concepts  followed  in  the 
design  of  the  Tactical  Situation  System  try  to  enhance  the 
correlation  between  the  2D  map  display  and  the  3D  flight 
guidance  display.  The  improvements  should  lead  to: 

•  a  better  situational  awareness  concerning  the  aircraft’s 
attitude  while  working  with  the  2D  map.  The  pilot  should 
be  enabled  to  maintain  the  flight  attitude  even  while 
working  with  the  map  for  a  longer  time; 

•  an  easier  identification  of  visual  objects  in  the  map  and 
the  3D  representation  for  navigational  purposes.  The  pilot 
should  be  assisted  in  finding  and  visually  identifying 
navigational  landmarks  in  either  display  and  correlating 
them  with  the  other  representation.  This  implies  that  the 
integrated  display  system  should  clearly  indicate  the 
common  displayed  area; 

•  an  intuitive  understanding  of  the  terrain  contour.  The 
pilot  should  be  able  to  match  the  different  representations 
of  the  terrain  elevation  without  adding  effort  and  therfore 
being  aware  of  the  surrounding  terrain  at  any  time.  Thus, 
he  can  reduce  the  risk  of  dangerous  terrain  proximity 
even  when  concentrating  on  the  map  display; 

•  a  sufficient  awareness  of  the  mission  plan  and  flight  path 
throughout  the  flight.  The  pilot  should  be  enabled  to 
correlate  the  overall  mission  plan  and  track  information 
from  the  2D  display  with  the  local  flight  guidance 
information  give  in  the  3D  display  which  leads  to  a  better 
understanding  of  the  temporary  actions  to  be  taken. 

In  order  to  achieve  the  desired  improvements  in  the  context 
of  human-centered  display  design  and  effective  crew 
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assistance,  the  following  methods  were  applied  and  symbols 

were  integrated  in  the  displays. 

•  The  map  display  is  overlayed  by  a  combined  bank/flight 
path  angle/pitch  rate  indicator  on  the  periphery.  Thereby, 
the  pilot  can  gather  information  on  attitude  and  attitude 
changes  of  the  aircraft  by  means  of  peripheral  vision 
while  focussing  on  the  central  map  for  any  task 
performance. 

•  The  actual  fields  of  view  (and  viewing  distances)  of  the 
synthetic  flight  guidance  overlay  and  the  imaging  sensor 
are  propagated  to  the  Tactical  Situation  Display  and 
indicated  by  triangles.  Thereby,  the  pilot  can  directly 
correlate  locations  on  the  map  and  in  the  perspective 
view. 

•  The  colour  coding  of  the  conformal  terrain  contour 
symbology  in  the  Enhanced  Flight  Guidance  Display  is 
identical  to  the  map  display.  Thereby,  the  pilot  can  easily 
identify  identical  terrain  relief  elements  such  as 
ridgelines  or  valleys  on  both  displays.  The  same  principle 
is  applicable  for  the  terrain  collision  warning  colouring  in 
both  displays.  This  feature  allows  the  pilot  to  recognize 
terrain  proximity  by  just  regarding  the  map  display. 

•  The  generated  low-altitude  flight  plan  is  transmitted  to 
the  map  and  flight  guidance  display  in  parallel. 


5  EVALUATION  CONCEPTS 

In  order  to  evaluate  the  approaches  to  crew  assistance, 
particularly  the  Tactical  Situation  System,  software 
prototypes  are  implemented  and  integrated  in  appropriate  test 
enviromnents.  The  tests  are  being  done  with  respect  to 
technical  feasibility,  human-machine-interaction 

considerations,  and  real-world  conditions.  Therefore,  the 
Tactical  Situation  System  and  various  subsystems  are 
presently  undergoing  critical  evaluation  procedures  which  are 
described  in  the  following  sections  broken  down  by  method. 


Figure  9  shows  the  structure  of  the  replay  system.  The 
approach  utilizes  pre-recorded  sensor  images  with  related 
flight  data  recordings  from  flight  trials.  The  replay  control 
feeds  the  flight  data  into  the  Flight  Guidance  Symbol 
Generator  while  starting  the  video  player  synchronously.  The 
video  overlay  is  either  done  digitally  with  appropiate 
hardware  in  the  graphics  workstation  or  optically  on  a 
projection  screen  using  two  projectors.  Thereby,  a  dynamic 
image  can  be  produced  in  a  laboratory  environment  which  is 
very  close  to  the  real-world  appearance. 

5.2  Human-machine-interaction  evaluation 

In  order  to  evaluate  the  system  under  human-machine- 
interaction  aspects,  the  prototypes  have  been  integrated  in  a 
flight  simulation  environment.  The  required  elements  are: 

•  The  dynamic  simulation  calculates  the  aircraft 
movements  and  models  the  subsystems’  behaviour 
according  to  the  pilot’s  control  actions. 

•  The  cockpit  simulation  is  the  human-machine-interface  to 
the  avionics  systems  prototypes  and  is  designed  as  a  tool 
for  any  human  performance/behaviour  and  acceptance 
studies.  The  cockpit  is  designed  as  a  glass-cockpit  with  a 
generic  layout  in  order  to  be  easily  adapted  to  different 
configurations.  Figure  10  shows  the  layout  of  the  display 
areas  and  the  controls  including  Primary  Flight  Displays 
(PFD),  a  Radio  Management  Unit  (RMU)  miming  on  a 
Control  and  Display  Unit  (CDU)  with  touchscreen 
control,  a  Flight  Control  Unit  (FCU),  a  sidestick,  throttle, 
and  application  monitors. 

•  The  visual  simulation  is  supposed  to  be  supporting  the 
activities  concerning  Enhanced  Flight  Guidance  Display. 
The  visual  simulation  will  be  built  by  use  of  a  projection 
system  (see  Figure  10). 

•  The  application  software  interface  allows  the  integration 
of  avionics  software  prototypes  in  order  to  evaluate  the 
functions  in  an  interactive  dynamic  flight  simulation 
environment.  Thereby,  it  is  possible  for  cockpit  crews  to 
directly  interact  with  the  systems  to  be  tested. 


5. 1  Functional  demonstration  and  technical  evaluation 

The  functional  demonstration  is  the  starting  point  of  any 
technical  evaluation.  Therefore,  the  subsystems  of  the 
Tactical  Situation  System  were  implmented  on  Silicon 
Graphics  UNIX  Workstations  using  the  C  programming 
language.  Particularly  the  Enhanced  Flight  Guidance  Display 
requires  additional  effort  in  order  to  develop  display  formats 
and  appropriate  symbology.  Presently,  a  development  tool  is 
being  built  which  allows  the  combination  of  the  synthetic 
parts  of  the  display  with  a  recording  of  a  sensor  image. 


Figure  9:  Sensor  image  recording  dynamically 
combined  with  synthetic  symbology 


Figure  10:  Cockpit  layout 


In  order  to  offer  an  opportunity  to  evaluate  the  Enhanced 
Flight  Guidance  Display  in  the  simulation  environment  with 
operational  flight  crews,  an  interactive  sensor  image 
simulation  is  presently  beeing  built.  It  is  based  upon  sensor 
characteristics  models  and  digital  terrain  elevation  and 
feature  data. 
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Ethernet 


Figure  11:  Hard-  and  software  architecture  of  the 
Avionics  System  Demonstrator,  ASD 


Figure  11  shows  the  open  hard-  and  software  architecture  of 
the  flight  simulation  system  (Avionics  System  Demonstrator, 
ASD).  Due  to  the  availability  of  the  entire  situation  relevant 
data  (held  in  the  Avionic  Interface  Data  Pool)  on  each 
integrated  computer  system,  other  prototype  systems  can  be 
integrated  easily  and  hardware-in-the-loop  testing  facilities 
can  be  provided. 

5.3  Field  trials  and  results 

Several  flight  trials  concerning  the  evaluation  of  Enhanced 
Flight  Guidance  Display  formats  have  been  conducted 
recently. 

The  following  overview  [11,  14]  provides  some  details 
concerning  the  recent  experimental  activities: 


Experiment  1: 
Time: 

December  ‘  94 

Terrain  structure: 

river  valley 

Plattform: 

Do  128 

Terrain  grid: 

no 

FUR: 

video  image  based  simulation 

Obstacle  cueing: 

yes 

Display  HW: 

helmet-mounted  display 

Objectives: 

principal  operationability 

Subjects: 

1  test  pilot 

Task: 

low-level  terrain  masking 

Result: 

HW/SW  operational  in  test  aircraft. 

Project  partner: 

pilot  is  able  to  stay  in  tunnel  and 
follow  river  valley 

TU  Munich,  TU  Braunschweig 

Experiment  2: 
Time: 

August  ‘95 

Terrain  structure: 

deep  mountain  valleys 

Plattform: 

Do  128 

Terrain  grid: 

yes 

FUR: 

video  image  based  simulation 

Obstacle  cueing: 

yes 

Display  HW: 

helmet-mounted  display 

Objectives: 

technical  operationability 

Subjects: 

1  test  pilot 

Task: 

missed  approach  procedures 

Result: 

slight  problems  with  hardware,  pilot 
is  able  to  follow  the  tunnel 

Project  partner: 
Experiment  3: 

TU  Munich,  TU  Braxmschweig 

Time: 

October  ‘95 

Terrain  structure: 

hilly  terrain 

Plattform: 

A  320  simulator 

Terrain  grid: 

no 

FUR: 

synthetic  digital  data  based  image 

Obstacle  cueing: 

yes 

Display  HW: 

head-up  display 

Objectives: 

pilot  acceptance 

Subjects: 

6  military  transport  pilots 

Task: 

low-level  (150  ft)  terrain  masking 

Result: 

system  is  well  accepted  by  pilots  as  a 
positive  assisting  function,  obstacle 
cueing  useful 

Project  partner: 
Experiment  4: 

DASA 

Time: 

March  ‘96 

Terrain  structure: 

hilly  terrain 

Plattform: 

Do  128 

Terrain  grid: 

yes 

FUR: 

video  image  based  simulation 

Obstacle  cueing: 

yes 

Display  HW: 

helmet-mounted  display 

Objectives: 

pilot  performance 

Subjects: 

1  test  pilot 

Task: 

low-level  terrain  masking 

Result: 

pilot  uttered  great  confidence  in  the 
system,  flight  could  be  successfully 
conducted  under  real  low  visibility 
conditions 

Project  partner: 

TU  Munich,  TU  Braunschweig 

The  first  two  experiments  were  conducted  in  order  to 
elaborate  the  configuration  of  the  aircraft  equipment  and  to 
demonstrate  the  principle  functional  operability  of  the 
system.  Several  enhanced  vision  guided  flights  through  a 
river  valley  in  southern  Germany  and  standard  missed 
approach  routes  from  an  airport  in  a  mountain  valley  could  be 
successfully  completed.  The  simulator  experiments  provided 
some  preliminary  results  with  respect  to  pilot  acceptance  in  a 
low-level  flight  task.  The  latest  flight  tests  aimed  to 
reproduce  the  simulator  flight  tasks  and  respective  mission 
plan  in  real  flight.  The  objective  was  the  measurement  of  the 
pilot’s  performance. 


6  CONCLUSIONS 

The  aim  of  the  presented  research  and  development  activities 
is  to  provide  advanced  cockpit  avionics  systems  improving 
the  crew’s  situational  awareness  with  respect  to  a  safe  and 
successful  mission  completion.  This  is  done  by  use  of 
technical  means  such  as  knowledge-based  on-board  systems 
in  the  context  of  human-centered  cockpit  automation.  The 
Crew  Assistant  Military  Aircraft  (CAMA)  yields  a  promising 
approach  to  assistance  in  planning  and  decision-making 
tasks.  The  Tactical  Situation  System  extracts  the  military 
operations  related  subsystems  which  are  the  Tactical 
Situation  Interpreter,  the  Low-altitude  Flight  Planner,  and  the 
Tactical  Situation  Display.  The  system  is  enlarged  by  the 
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Enhanced  Flight  Guidance  Display  which  offers  visual  flight 
guidance  information  to  the  crew  for  poor  visibility  low-level 
flight  operations.  Thereby,  crew  assistance  can  be  provided 
on  each  human  performance  level  including  highly  cognitive 
planning  tasks  as  well  as  sensomotoric  flight  control  tasks.  A 
major  aspect  of  the  prototype  development  is  the  intgration  of 
the  different  modules  in  order  to  achieve  an  efficient  assistant 
system.  Therefore,  the  interaction  between  the  2D  Tactical 
Situation  Display  and  the  3D  Enhanced  Flight  Guidance 
Display  is  emphasized  from  an  information  presentation  point 
of  view. 

In  order  to  evaluate  the  system  under  technical  and  human- 
machine-interaction  aspects,  software  prototypes  are  being 
developed  and  integrated  in  a  flight  simulation  environment. 
The  Enhanced  Flight  Guidance  Display  has  already  been 
successfully  tested  in  several  flight  trials.  The  results  show 
that  this  approach  to  visual  flight  guidance  assistance  is 
extremely  powerful  and  yields  a  high  potential  for  further 
developments  in  the  field  of  human-centered  cockpit  design. 
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1  SUMMARY 

Sensor  Fusion  has  become  important  for  fighter  aircraft 
in  order  to  improve  the  air  picture  with  respect  to  the 
displayed  area  of  all  sensors,  the  precision  of  target’s 
kinematic  data,  the  confidence  in  the  target’s  identity, 
and  to  support  the  management  of  the  sensors.  The  pa¬ 
per  investigates  system  architectures  of  existing  and  fu¬ 
ture  sensors.  Based  on  a  Bayesian  fusion  approach,  the 
benefits  and  constrains  of  data  throughput,  accuracy  and 
track  consistency  is  shown.  The  results  of  simulation 
runs  with  radar,  IR  and  ESM  sensor  models  togetlier 
with  a  data  link  network  are  presented. 

2  KEYWORDS 
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3  INTRODUCTION 

Existing  fighter  aircraft  present  their  sensor  information 
on  separate  displays  or  indicators  to  the  pilots,  and  the 
aircrew  must  fuse  and  evaluate  the  information.  With  in¬ 
creasing  complexity  of  the  scenarios,  more  onboard  sen¬ 
sors,  the  capability  of  the  sensors  to  process  more  tar¬ 
gets,  and  the  multirole  capability  of  modem  fighters,  the 
requirements  for  pilot  support  functions  to  evaluate  all 
this  multisensor  data  has  become  essential.  Additionally 
the  bandwidth  of  data  link  networks  has  been  increased 
and  allows  the  exchange  of  near  real-time  kinematic  and 
identity  data  among  fighters,  AEWs  and  C2  units.  New 
aircraft  developments,  like  the  European  EF  2000,  the 
American  F-22,  as  well  as  combat  improvements  of  ex¬ 
isting  aircraft  will  have  Sensor  or  Data  Fusion  facilities. 

In  the  past  20  years  Sensor  Fusion  has  been  llioroughly 
investigated  and  numerous  literature  is  available  [e.g.  1, 
2,  3].  The  Joint  Directors  of  Laboratories  Data  Fusion 
Subpanel,  a  DoD  US  Government  panel,  has  defined  a 
functional  description  with  different  levels.  The  first 
level  defines  the  combination  of  kinematic  and  identity 
data,  the  second  the  situation  assessment,  the  third  the 
threat  assessment,  and  the  fourth  which  is  often  part  of 
the  first  level  optimises  the  management  of  the  sensors 
in  order  to  improve  the  kinematic  and  identity  data. 

It  is  obvious  that  only  parts  of  this  general  description 
for  Sensor  Fusion  can  be  used  for  fighter  aircraft.  The 
Level  1  taxonomy  is  well  established  and  numerous 
publications  are  available,  whereas  Level  2  to  4  are  not 


properly  defined  and  visualise  the  different  aspects  to  be 
considered. 

This  paper  describes  architectures  for  Sensor  Fusion  in  a 
fighter  aircraft,  based  on  the  capabilities  and  constrains 
of  the  sensors  which  are  available  or  under  develop¬ 
ment.  It  investigates  solutions  for  Level  1  and  Level  4 
functions  and  their  impacts  on  the  process  load  and  the 
data  accuracy.  Level  2  and  3  aspects  are  not  considered. 

4  OPERATIONAL  BACKGROUND 

The  primary  role  of  a  fighter  aircraft  is  the  air-to-air 
mission  which  comprises  the  ak  defence  and  the  offen¬ 
sive  bomber  escort  role.  As  a  secondary  role  different 
air-to-ground  missions  must  be  considered.  In  addition 
with  the  availability  of  powerful  data  link  networks,  an¬ 
other  role,  the  contribution  of  kinematic  and  identity  tar¬ 
get  data  by  the  fighter  aircraft  to  the  air  picture  of  the 
network  becomes  important. 

An  important  number  is  the  amount  of  tracks  which 
have  to  maintained  onboard  the  fighter  aircraft.  The  lit¬ 
erature  refers  to  10  to  30  tracks  to  be  relevant  for  a  mis¬ 
sion  [1].  If  however  a  complete  air  picture  for  a  mission 
area  must  be  observed,  the  number  of  tracks  can  exceed 
200. 

In  its  primary  role  the  fighter  has  to  gain  a  superior  posi¬ 
tion  to  win  the  air  fight  against  hostile  fighter  aircraft, 
usually  together  with  co-operating  fighters.  Addition¬ 
ally,  low  flying  bombers  must  be  intercepted  in  the  air 
defence  role. 

In  these  situations  fighters  have  the  problem  that  the  air 
picture  provided  from  a  single  sensor,  the  own  radar,  is 
insufficient  with  respect  to  the  observed  space,  the  iden¬ 
tity  and  the  number  of  the  tracks.  In  the  beyond  visual 
range  attack,  launched  missiles  must  be  supported  with 
track  data,  as  accurate  as  possible  to  improve  the  prob¬ 
ability  of  intercept.  Therefore  the  tracks  against  which 
the  missiles  are  fired  require  a  higher  update  rate  with 
the  consequence  that  other  tracks  may  be  lost  or  become 
inaccurate. 

In  the  secondary  role  the  problem  of  an  insufficient  air 
picture  from  qbove  is  amplified,  because  the  fighter  is 
flying  at  lower  levels,  and  a  single  sensor  must  be  util¬ 
ised  for  the  target  acquisition  or  as  flying  aid. 

The  problems  mentioned  above  cannot  be  totally  re¬ 
solved  due  to  the  stochastic  characteristics  of  a  scenario. 
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Any  air  or  ground  track  has  a  certain  uncertainty,  may 
be  at  the  wrong  position,  or  may  have  an  incorrect  iden¬ 
tity.  A  certain  probability  exists  that  a  real  target  is 
never  detected  or  a  track  in  the  air  picture  is  a  ghost. 

With  Sensor  Fusion  the  synergy  of  the  different  sensors 
can  be  used  to  minimise  these  problems.  If  the  whole 
spectrum  from  IR  to  radio  frequencies  is  observed,  the 
detection  probability  is  increased  and  the  vulnerability 
to  hostile  deception  techniques  is  decreased.  If  severi 
sensors  provide  data  about  the  same  target,  the  quality 
of  the  kinematic  data  is  improved  and  confidence  in  the 
identity  is  augmented.  The  space  to  be  observed  can  be 
split  in  different  sensor  regions  whereby  one  sensor  can 
be  supported  by  another  sensor  provided  his  kinematic 
or  identity  data  are  insufficient. 

5  SENSORS 

Sensor  Fusion  is  determined  by  the  quality  of  the  data 
provided  by  the  onboard  sensors  and  the  external  data 
from  the  data  link  network.  The  crucial  aspects  are  the 
accuracy  and  the  latency  of  the  kinematic  data,  e.g. 
range,  range  rate  and  angles,  the  search  volume  of  the 
sensors,  and  the  confidence  in  the  identity  declarations'. 

5.1  Multi  Mode  Fighter  Radar 

The  advantages  of  a  multi  mode  radar  with  a  frequency 
range  from  8  GHz  to  12  (20)  GHz  compared  with  other 
sensors  are  its  insensitivity  with  respect  to  the  environ¬ 
mental  conditions,  its  possibility  to  measure  the  range 
and  the  range  rate  additionally  to  the  angles,  at  least  in  a 
benign  environment,  and  its  possibility  to  discriminate 
air  or  ground  targets  from  the  background  clutter.  Addi¬ 
tionally  the  radar  provides  non-cooperative  identifica¬ 
tion  facilities  by  the  so-called  Jet  Engine  Modulation 
(JEM)  and  High  Precision  Ranging  (HPR). 

The  disadvantages  are  its  radiation  which  allow  other 
sites  the  detection  and  identification  at  long  distances, 
and  the  limited  search  volume.  In  a  hostile  environment 
the  range  and  range  rate  is  difficult  to  achieve  and  there 
is  a  competition  between  hostile  jamming  techniques 
and  the  anti-jamming  capability  of  the  radar. 

The  accuracy  of  the  radar  data  highly  depend  on  the 
number  of  tracks  it  must  maintain.  If  20  tracks  must  be 
maintained,  a  search  volume  of  100  deg  x  6  deg  x 
100  km  with  4  s  frame  time  is  typical.  Then  the  track  ac¬ 
curacy  for  the  delivery  of  beyond  visaul  range  missiles 
against  highly  manoeuvring  targets  is  insufficient.  The 
probability  that  the  tracks  are  lost  is  high,  and  the  targets 
may  fly  out  of  the  search  volume  too  fast.  The  same  ef¬ 
fect  may  occur,  if  low  flying  bombers  and  high  flying 
fighters  must  be  simultaneously  tracked.  For  a  head-on 
scenario  the  detection  range  is  too  short  to  establish  con¬ 
firmed  tracks,  identify  the  targets,  and  to  perform  the 
target  assignments  in  co-operation  with  other  fighters  or 
a  C2  unit. 

These  problems  may  be  partially  resolved  by  new  deve¬ 
lopments  in  the  radar  technology,  like  adaptive  sam¬ 
pling,  better  manoeuvre  modelling  in  the  tracker,  or  im¬ 
provements  of  the  signal  processing.  But  the  physical 
constrains  of  the  antenna  diameter,  the  available  power 


and  the  signal-to-noise  ratio  will  always  define  one 
boundary  condition  and  the  required  time  on  target  for 
non-cooperative  identification  and  precise  Doppler 
measurements  the  other. 

With  50  ms  to  100  ms  time  on  target,  20  tracks  require 
1  s  to  2.5  s  frame  time  with  adaptive  sampling.  If  2  s  are 
used  for  the  search  of  new  targets,  a  frame  time  of  ap¬ 
proximately  4  s  results  with  the  problems  described 
above.  Therefore,  the  time  between  two  target  updates 
must  be  shortened.  But  if  10  to  30  relevant  tracks  have 
to  be  maintained  onboard  the  fighter,  other  sensors  must 
be  used  to  support  the  radar. 

5.2  Missile  Radar 

If  the  fighter  is  equipped  with  missiles  which  have  a  ra¬ 
dar  seeker  head  the  missiles  can  contribute  target  data  in 
their  lock  follow  mode  with  a  high  update  rate.  Such  a 
design  is  limited  by  the  detection  range  and  the  aperture 
of  the  missile  radars.  If  a  missile  radar  is  capable  to 
track  a  target  beyond  visaul  range  no  post  launch  sup¬ 
port  would  be  required  and  the  missile  could  be  used  as 
a  fire  and  forget  weapon.  Usually  the  missile  radar  has 
not  this  capability  and  needs  a  post  launch  support. 
Therefore,  only  targets  considerably  inside  a  range 
where  a  successful  missile  launch  is  possible  can  be 
tracked.  But  these  tracks  should  represent  the  less  im¬ 
portant  targets. 

5.3  Optica!  Sensor 

The  spectral  region  from  0.4  pm  to  14  pm  offers  four 
detection  windows,  one  in  the  visible  and  three  in  the  IR 
region.  Sensors  operating  in  the  visible  spectrum  are 
limited  by  weather  conditions.  The  benefits  of  the  better 
angular  resolution  compared  with  the  IR  region  cannot 
compensate  these  constrains.  Therefore  only  the  search 
and  tracking  function  of  an  IR  sensor,  an  IRST,  is  feasi¬ 
ble  for  fighter  aircraft. 

The  advantages  of  an  IRST  are  its  passive  mode  of  op¬ 
eration  and,  compared  with  the  radar,  its  theoretical  bet¬ 
ter  angular  resolution.  The  disadvantages  are  the  sensi¬ 
tivity  of  the  detection  range  with  respect  to  weather 
conditions,  and  the  impossibility  to  measure  range  and 
range  rate.  The  IRST  tracker  based  on  angular  measure¬ 
ments  only  needs  therefore  more  time  to  provide  an  ap¬ 
propriate  target  position  than  a  radar  which  measures 
additionally  the  range  and  range  rate. 

The  advantage  of  the  passive  mode  of  operation  is  on 
the  other  hand  a  disadvantage,  because  the  IRST  cannot 
support  a  beyond  visaul  range  missile  after  launch.  As 
the  radar  is  the  primary  sensor  of  a  fighter  aircraft,  in¬ 
stallation  problems  exist,  which  cause  obscuration  ef¬ 
fects  with  respect  to  the  vertical  or  horizontal  plane. 
Compared  with  the  detection  range,  the  identification 
capability  from  image  analysis  is  poor  due  to  the  diffrac¬ 
tion  criteria.  Classification  of  targets  may  be  achieved  at 
sufficient  distances  if  all  three  IR  windows  are  exam¬ 
ined,  which  requires  two  separate  detector  arrays. 

These  problems  cannot  be  resolved  within  a  single 
IRST.  Even  by  using  a  LASER  for  the  the  slant  range 
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measurement  the  detection  range  would  be  too  poor 
compared  with  a  radar. 

But  in  conjunction  with  other  sensors  these  disadvan¬ 
tages  can  be  be  avoided.  Another  sensor  can  prime  the 
IRST  with  range  and  range  rate  information,  for  the 
track  initialisation.  With  this  initialisation  data  the  IRST 
can  track  a  target  for  a  sufficient  time.  The  fighter  radar 
and  the  IRST  can  co-operatively  track  the  relevant  tar¬ 
gets,  by  splitting  the  search  volume  and  dividing  the 
frame  time  in  halve.  With  a  more  sophisticated  sensor 
management  the  reduction  of  the  track  update  time  can 
be  achieved  if  both  sensors  observe  the  same  volume. 

5.4  Missile  with  IR  Seeker  Head 

Missiles  with  IR  seeker  heads  may  be  used  in  the  same 
way  as  missiles  with  a  radar  seeker  head.  But  the  mis¬ 
siles  with  an  IR  sensor  can  provide  data  with  the  same 
accuracy  as  the  onboard  sensor,  the  IRST,  because  the 
aperture  and  the  signal  to  noise  ratio  defining  factors  are 
comparable. 

Therefore  measurements  or  track  data  from  IR  missiles 
are  candidates  for  Sensor  Fusion  in  a  fighter  aircraft.  If 
the  IR  seeker  head  is  primed  with  target  data  from  an¬ 
other  sensor,  it  can  continuously  provide  target  data  with 
good  angular  accuracies. 

5.5  IFF  Interrogator 

The  advantage  of  an  IFF  interrogator  is  the  detection 
range  due  to  the  co-operative  measurement.  The  range 
resolution  is  sufficient  as  well  as  the  angular  resolution 
of  a  monopuls  IFF.  Together  with  a  Mode  3/C  response 
a  sufficient  three  dimensional  location  can  be  achieved. 
The  crypto  Mode  4  provides  a  good  anti  spoofing  capa¬ 
bility.  The  Mode  1,  2  or  3/A  can  be  used  for  tracking 
purposes  to  distinguish  different  co-operating  tracks 
from  each  other.  The  disadvantage  of  an  IFF  is  that  it  is 
designed  to  operate  in  conjunction  with  2D  surveillance 
radars.  Therefore  it  provides  only  an  azimuth  angle.  For 
fighters  whose  radar/IFF  antenna  has  no  roll  compensa¬ 
tion  this  causes  significant  problems,  because  the  pre¬ 
cise  azimuth  now  depends  on  the  aircraft  manoeuvres. 

The  use  of  the  IFF  interrogator  depends  on  the  opera¬ 
tional  constrains.  If  it  is  used  in  a  continuous  mode,  it 
permanently  emits  interrogations  in  the  search  volume. 
The  received  responses,  together  with  the  radar  meas¬ 
urements,  can  be  used  to  update  the  tracks.  If  the  IFF  in¬ 
terrogator  is  used  for  identification  purposes  only,  the 
continuous  interrogation  of  the  whole  space  is  superflu¬ 
ous.  In  this  case  only  unknown  tracks  from  other  sensors 
are  interrogated.  In  both  cases  Sensor  Fusion  is  required, 
because  the  IFF  responses  must  be  associated  with  other 
tracks,  the  kinematic  data  may  be  used  to  update  the  tar¬ 
get  positions,  and  the  received  responses  are  used  to 
identify  the  targets. 

5.6  ESM/LW/MAW 

The  ESM,  LW  and  MAW  are  warning  sensors  aboard  a 
fighter  aircraft.  The  advantage  of  an  ESM  is  its  detec¬ 
tion  range  and  all  three  sensors  can  detect  emissions 
from  any  direction.  The  ESM  can  identify  hostile  target 


types  if  they  are  contained  in  its  emitter  library.  The  dis¬ 
advantage  of  all  warning  sensors  are  their  inaccurate  an¬ 
gular  target  data  and  that  the  target  range  can  only  be 
derived  from  the  emitter  library. 

Therefore  it  is  difficult  to  associate  identity  data  from 
ESM,  LW  or  MAW  sensors  with  tracks  from  other  sen¬ 
sors  in  a  dense  scenario.  Solutions  for  this  problem  are 
the  use  of  the  more  precise  identity  information  of  the 
sensors  for  the  the  association.  But  this  requires  that  the 
track  to  which  the  ESM  identity  information  is  assigned 
to,  e.g.  a  radar  track,  must  contain  identity  data.  Another 
solution  makes  use  of  the  statistical  independence  of 
kinematic  track  data  from  a  radar  or  an  IRST  and  the 
ESM  angles  [4].  The  normalised  distances  can  subse¬ 
quently  summed  up,  the  uncertainties  decease  and 
wrong  correlation  pairs  will  be  sorted  out  by  their  in¬ 
creasing  biases.  This  requires  that  ESM  does  not  con¬ 
fuse  the  angles  of  arriv^  of  the  radiating  targets  and 
track  these  targets  by  their  identity  data. 

5.7  Data  Link  Network 

Within  a  data  link  network  the  exchange  of  target 
kinematic  and  identity  data  is  possible.  Network  partici¬ 
pants  can  provide  their  own  position,  their  target  tracks, 
or  their  sensor  measurements.  Compared  with  the  on¬ 
board  sensors  the  problem  of  a  common  co-ordinate  sys¬ 
tem,  and  a  common  time  becomes  more  severe. 

The  applicability  of  these  data  depends  on  the  physical 
link  and  the  bandwidth  of  the  network.  The  physical  link 
must  assure  that  the  messages  can  be  received  by  the  ad¬ 
dressee  and  the  message  cannot  be  encoded  or  jammed 
by  a  hostile  site.  The  bandwidth  must  assure  that  all  data 
are  exchanged  with  a  minimum  latency. 

Within  a  mission  area  controlled  by  a  C2  unit,  three 
types  of  data  sources  can  be  distinguished.  The  C2  unit 
provides  its  air  picture,  network  participants  a  self  iden¬ 
tification,  and  if  they  have  own  sensors,  their  sensor  data 
can  be  transmitted. 

The  C2  unit  provides  its  own  air  picture  from  its  C2  ra¬ 
dar,  from  an  AEW  aircraft  or  from  neighbour  C2  units. 
The  tracks  may  exceed  the  above  mentioned  200,  but 
the  accuracy  of  the  kinematic  data  may  be  low  due  to 
the  update  rates  and  the  measurement  characteristics  of 
the  C2  radars.  The  subsequent  changes  of  the  co¬ 
ordinate  systems  require  numerous  data  for  a  complete 
description  of  the  track  uncertainties.  Actual  systems 
have  not  the  capability  to  provide  these  parameters  and, 
due  to  historical  reasons,  use  simplified  descriptions  like 
a  Circular  Error  Probability  (CEP);  This  generates  addi¬ 
tional  uncertainties  and  biases.  The  identity  of  the  C2 
U-acks  is  usually  more  confident  than  the  track  identity 
of  a  single  site,  because  a  C2  unit  has  access  to  more 
identity  information. 

Network  participants  like  other  fighters  provide  their 
own  kinematic  data  for  self  identification  purposes.  The 
accuracy  should  be  high,  and  if  the  fighter  has  a  GPS  in 
its  navigation  system,  the  uncertainties  can  be  described 
by  a  CEP. 
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Any  non-C2  unit  with  onboard  sensors  like  radar,  IRST, 
IFF  or  ESM  can  contribute  its  kinematic  and  identity 
target  data.  For  the  description  of  the  uncertainties  there 
exist  a  similar  problem  as  for  the  C2  unit.  Another  as¬ 
pect  is  whether  raw  data  like  kinematic  measurement  or 
identity  declarations,  or  filtered  data  like  tracks  and 
identity  likelihood  vectors  should  be  transmitted.  The 
different  aspects  are  discussed  in  Chapter  5. 

It  is  easy  to  implement  a  unique  definition  of  the  tracks 
from  the  C2  unit  and  the  self  identification  data  of  the 
network  participants  by  appropriate  identifiers  within 
the  network.  For  their  combination  no  Sensor  Fusion  is 
required.  Tracks  or  measurements  from  non-C2  sites  are 
not  unique  and  messages  from  different  sites  may  de¬ 
scribe  the  same  target.  A  Sensor  Fusion  for  the  unifica¬ 
tion  of  the  messages  is  therefore  required  for  which  dif¬ 
ferent  design  alternatives  are  possible. 

A  hierarchy  design  associates  the  tracks  at  a  central 
node,  the  C2  unit.  The  non-C2  sites  receive  only 
uniquely  identified  track  data  from  other  sites,  the  other 
messages  are  ignored.  Such  a  design  requires  Sensor  Fu¬ 
sion  only  for  the  C2  unit,  but  it  is  inflexible  with  respect 
to  time  constrains  and  the  data  exchange  without  a  C2 
unit. 

A  distributed  design  allows  each  network  participant  to 
associate  and  fuse  the  received  data  at  their  own  plat¬ 
form,  together  with  the  onboard  sensor  data.  Different 
results  may  may  occur  at  each  fusion  node,  and  strate¬ 
gies  for  their  resolution  must  be  designed. 

6  DESIGN  PRINCIPLES 

6.1  Architecture  Alternatives 

The  design  of  Sensor  Fusion  systems  is  highly  depend¬ 
ent  on  the  sensor  hardware.  Sensors,  responsible  for  the 
estimation  of  the  target  kinematics,  like  the  radar  or 
IRST,  have  a  tracking  system  and  provide  only  track 
data  but  no  measurements.  Other  sensors  without  a 
tracker  like  the  IFF  or  the  ESM  can  supply  only  their 
measurements. 

Two  main  design  principles  and  numerous  mixtures  are 
are  published  [3,5]: 

1.)  A  sensor  level  architecture  combines  the  tracks  of 
the  individual  sensors, 

2)  a  centralised  architecture  where  all  the  sensor  meas¬ 
urements  are  fed  to  a  central  tracker,  and 

3)  combined  architectures  which  utilise  measurements 
and  track  data,  dependent  on  the  situation,  or  exchange 
the  results  between  the  sensors  and  fusion  nodes. 


6.1.1  Sensor-Level  or  Autonomous  Architecture 

The  autonomous  or  sensor-level  architecture  has  a  track¬ 
ing  system  in  each  sensor.  The  sensors  provide  their 
tracks  to  a  central  fusion  node  which  associates  the  data 
by  a  track-to-track  correlation.  Data  which  belong  to  the 
same  target  may  be  merged  in  order  to  improve  the 


kinematic  data,  or  it  is  simply  indicated  which  sensor 
track  represents  the  same  target,  in  order  to  declutter  the 
air  picture. 

The  advantage  of  such  an  architecture  is  that  existing 
sensors  can  be  used.  Only  minor  modifications  are  re¬ 
quired,  because  the  track  data,  provided  from  most  sen¬ 
sors,  do  not  contain  all  the  accuracy  and  tracker  data  re¬ 
quired  for  the  association  and  fusion.  But  all  these  data 
are  available  within  the  sensors.  The  data  transfer  is  not 
significantly  increased,  because  the  track  update  time  is 
typically  between  1  s  and  5  s  and  no  measurements  must 
be  transmitted  via  the  bus.  All  individual  sensors  main¬ 
tain  their  own  tracks  which  guarantees  a  high  redun¬ 
dancy.  If  one  sensor  becomes  degraded,  tracks  of  the 
other  sensors  are  not  affected. 

The  disadvantage  of  the  sensor-level  architecture  com¬ 
pared  with  the  centralised  architecture,  is  the  lower  ac¬ 
curacy  of  the  fused  tracks.  The  continuity  of  the  fused 
track  compared  with  the  sensor  tracks  cannot  be  signifi¬ 
cantly  improved.  As  a  result,  tracks  which  are  lost  or 
confused  by  a  single  sensor  due  to  its  low  update  rate 
and/or  target  manoeuvres,  are  often  lost  at  the  fusion 
node  of  the  central  unit.  The  correlation  and  fusion  algo¬ 
rithms  are  complex  due  to  the  statistical  dependencies  of 
the  tracks. 


6.1 .2  Centralized  Architecture 

For  the  centralised  architecture  the  measurements  of 
each  individual  sensor  are  fed  to  the  central  fusion  node, 
where  the  measurement-to  track  association  and  the 
tracking  of  the  targets  is  performed.  This  approach  pro¬ 
vides  the  best  accuracies  of  all  architectures  [6].  As  a 
consequence  the  missassociation  is  less  severe  than  for 
the  sensor  level  arcitecture.  The  association  and  the 
track  update  equations  are  simple,  due  to  the  statistical 
independence  of  sensor  measurements  and  tracks.  Com¬ 
pared  with  a  single  sensor  track,  the  continuity  of  the 
central  track  is  better  and  it  is  faster  converged,  because 
the  update  rate  is  increased. 

The  disadvantage  of  a  centralised  architecture  is  the 
high  data  transfer  load  on  the  data  bus  due  to  the  clutter, 
false  alarms  etc.  received  in  the  sensors.  As  a  result  of 
this  high  amount  of  data  the  processing  load  for  the  as¬ 
sociation  will  also  increase  and  the  track  initialisation 
and  deletion  are  more  complex.  The  architecture  is  more 
vulnerable  to  degraded  sensor  data,  and  the  redundancy 
is  a  problem,  because  the  whole  air  picture  is  lost,  if  the 
central  fusion  node  fails.  Due  to  the  amount  of  measure¬ 
ments  from  the  different  sensors  the  processing  load  for 
the  association  may  become  too  high. 


6.1.3  Combined  Architectures 

Numerous  other  approaches  exist  to  overcome  the  prob¬ 
lems  of  the  first  two  approaches,  without  loosing  then- 
benefits. 

One  alternative  is  the  implementation  of  both,  a  track- 
to-track  and  a  measurement-to-track  correlation  and  fu¬ 
sion  at  the  central  fusion  node.  To  avoid  track  initialisa- 
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tion  problems  the  sensor  level  track  files  are  used  to  in¬ 
itiate  or  delete  the  central  tracks.  If  more  accurate  track 
data  is  required,  the  central  fusion  node  is  switched  from 
the  track-to-track  to  measurement-to-track  correlation. 
The  sensor  level  track  files  can  be  used  to  reduce  the 
data  bus  load,  if  only  measurements  which  have  updated 
the  sensor  level  tracks  are  fed  to  the  central  track. 

Another  alternative  is  the  feed  back  of  information  be¬ 
tween  the  central  fusion  node  and  the  sensors.  The  sen¬ 
sors  provide  their  tracks  to  the  central  fusion  node  which 
performs  a  track-to-track  correlation  and  fusion.  The  re¬ 
sults  of  the  fusion,  the  state  vectors  of  the  tracks  and 
their  covariances,  are  periodically  send  back  to  the  sen¬ 
sors  in  order  to  improve  the  sensor  level  tracks.  This  im¬ 
proves  the  continuity  and  accuracy  of  the  sensor  level 
tracks,  particularly  for  sensors  which  utilise  angle  only 
measurements  for  their  trackers.  The  approach  is  appli¬ 
cable  for  both  a  data  link  network  and  within  a  fighter 
aircraft,  because  the  maximum  data  transfer  load  is  pre¬ 
determined  by  the  number  of  tracks  and  the  time  inter¬ 
vals  between  the  messages  from  one  network  participant 
to  another,  or  from  the  sensors  to  the  central  fusion  node 
and  vice  versa. 

6.2  Processing  Functions 

The  taxonomy  for  the  processing  of  kinematic  data  is 
well  established  in  the  literature.  Most  of  the  functions 
can  be  compared  with  the  processing  of  a  single  sensor. 
The  steps  are  (1)  the  alignment  of  the  data  with  respect 
to  the  time  and  the  co-ordinate  system,  (2)  the  gating 
and  the  calculation  of  a  suitable  distance  measure  be¬ 
tween  the  tracks  or  the  measurements  and  the  tracks,  (3) 
a  formation  of  clusters  to  form  group  tracks  and  to  sup¬ 
port  the  identification,  (4)  the  assignment  of  measure¬ 
ments  or  sensor  tracks  to  a  central  track,  and  (5)  the  fu¬ 
sion  of  the  identity  and  the  kinematic  data  of  the  sensor 
reports. 


6.2.1  Alignment 

For  a  single  sensor,  like  a  radar,  the  time  alignment  is 
the  prediction  of  the  track  state  vectors  and  their  covari¬ 
ance  matrices  from  the  last  track  update  time  to  the  time 
of  new  measurements.  The  co-ordinates  of  the  measure¬ 
ments  and  their  uncertainties  are  transformed  to  the  co¬ 
ordinate  system  of  the  tracks. 

The  same  process  is  required  for  the  centralised  archi¬ 
tecture,  to  perform  the  measurement-to-track  association 
in  the  central  fusion  node.  Different  co-ordinate  trans¬ 
formations  may  be  required  to  account  for  the  character¬ 
istics  of  each  individual  sensor. 

In  the  sensor  level  architecture  the  central  fusion  node  or 
the  sensors  themselves  can  perform  the  time  and  the  co¬ 
ordinate  alignment.  For  the  onboard  sensors  a  spherical 
geodetic  (North,  East,  Down)  co-ordinate  system  is  suit¬ 
able.  For  sensors  which  provide  their  track  data  in  this 
co-ordinate  system  no  co-ordinate  transformation  is  re¬ 
quired  and  the  time  alignment  can  be  simplified.  Often  a 
time  alignment  may  be  omitted,  because  the  effect  of  the 
extrapolation  is  negligible  compared  with  the  sensor  ac¬ 
curacies,  e.g.  for  a  radar-ESM  correlation. 


The  transformation  of  tracks  from  the  data  link  network 
requires  more  effort,  because  the  tracks  must  be  trans¬ 
formed  from  a  co-ordinate  system,  suitable  for  all  net¬ 
work  participants,  e.g.  a  Word  Geodetic  System 
(WGS  84),  to  an  onboard  system.  If  the  track’s  uncer¬ 
tainty  is  described  by  a  single  CEP,  some  effort  is  re¬ 
quired  to  reconstruct  a  suitable  uncertainty  description. 
If  a  covariance  matrix  or  an  error  ellipse  is  available  it 
must  be  transformed  to  the  onboard  co-ordinate  system. 


6.2.2  Gating  and  Distance  Measure 

The  gating  is  used  to  determine  the  measurements  or 
tracks  of  the  sensors  which  belong  to  the  same  target. 
Usually  rectangular  and/or  elliptical  gates  are  used  for 
this  purpose. 

Equation  (1)  shows  an  example  for  the  rectangular  gate 
of  the  range  estimates  from  different  sensors. 

Ig(0-^2W|  ^  const.  (1) 

The  gate  size  is  defined  by  the  uncertainties  of  the  meas¬ 
urements  and  the  tracks  or  by  the  uncertainties  of  the 
two  tracks.  If  the  difference  of  the  state  vector  compo¬ 
nents  is  less  than  the  gate  size,  the  two  tracks  are  sub¬ 
jected  to  further  association  processing. 

The  rectangular  gates  are  cheap  to  implement  from  the 
processing  power  point  of  view,  and  if  their  hierarchy  is 
well  designed  most  of  the  unlikely  combinations  may  be 
sorted  out  after  the  first  gate. 

If  several  candidates  belong  to  the  same  rectangular  gate 
an  appropriate  distance  measure  must  be  calculated.  For 
measurement  to  track  association  the  normalised  dis¬ 
tances  together  with  their  residuals,  known  from  Kal¬ 
man  filter,  are  applicable. 

Equation  (2)  describes  the  normalised  distance,  d,  for 
two  tracks  with  the  state  vectors  ^i(f)  and  X2(t) : 

[^l(f)-  ^2(0]  =  ^  (2) 

with: 

S  =  Pi  +  Pi-  P\2-  Pu 

Due  to  the  common  manoeuvre  noise  the  cross  covari¬ 
ance  matrix  Pj2  must  be  considered  in  addition  to  the 
track  covariance  matrices  and  P2  of  the  single  sen¬ 
sors.  Fj2  depends  on  the  filter  gains,  the  manoeuvre 
models  and  the  measurement  matrices  of  the  sensor  and 
Pj2  the  the  previous  normalised  distance  [7].  They 
are  therefore  difficult  to  evaluate  because  these  data  are 
usually  neither  provided  from  the  onboard  sensors  nor 
from  a  data  link  network. 
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6.23  Clustering 

Usually  the  distance  measure  is  used  to  perform  the  final 
assignment  of  the  tracks  or  measurement.  But,  in  a 
dense  scenario,  with  200  tracks,  the  assignment  matrix 
may  become  too  large.  Additionally,  the  assignment  is  a 
probabilistic  process  which  selects  the  most  likely  track 
pair.  If  there  are  several  candidates  the  probability  that 
the  solution  is  correct  is  often  poor,  because  the  prob¬ 
ability  of  other  track  pairs  may  be  comparable.  This  may 
occur  for  a  radar-ESM  association.  Assuming  a  Nearest 
Neighbour  (NN)  algorithm  would  be  applied  for  the  as¬ 
sociation  of  many  tracks  with  good  identities,  but 
kinematic  data  with  large  variances,  an  identification 
conflict  would  possibly  occur,  because  the  kinematic 
correlation  would  not  assign  the  tracks  correctly. 

Clustering  is  a  measure  to  overcome  these  problems.  By 
the  clustering  large  assignment  matrices  can  be  parti¬ 
tioned  into  smaller  ones.  Unique  track  pairs  can  be 
sorted  out.  Clusters  with  several  tracks,  but  the  same 
identity,  may  form  a  group  track. 


6.2.4  Assigment 

The  assignment  is  known  from  the  NN  approach  of  a 
single  sensor,  where  a  measurement  is  used  for  the  up¬ 
date  of  its  nearest  track  only,  instead  of  a  probabilistic 
approach  were  measurements  can  update  all  tracks  to 
which  they  may  belong. 

For  the  track-to-track  correlation  a  NN  approach  is  ap¬ 
propriate.  The  distance  measures,  derived  in  the  associa¬ 
tion,  are  the  elements  of  the  assignment  matrix.  The 
number  of  sensor  tracks  which  belong  to  the  same  clus¬ 
ter  define  its  dimension.  Numerous  optimal  and 
suboptimal  approaches  are  known.  The  Munkres  algo¬ 
rithm  [8]  is  a  favourite  of  the  optimal  assignments.  Un¬ 
fortunately  the  processing  load  increases  with  an  expo¬ 
nent  between  two  and  three  if  the  number  of  tracks, 
which  belong  to  the  same  cluster,  increase.  Therefore  a 
suboptimal  assignment  algorithm,  which  increase  with 
an  exponent  of  two,  is  sufficient,  if  only  a  display 
declutter  is  required. 


6.2.5  Fusion 

The  centralised  architecture  requires  a  fusion  algorithm, 
e.g.  a  Kalman  filter  at  the  central  fusion  node.  For  the 
sensor  level  achitectures  one  representative  sensor  level 
track  is  often  sufficient  to  describe  the  target  kinematics. 
Only  if  the  accuracy  of  a  track  is  insufficient,  or  if  the 
estimates  of  the  central  fusion  node  are  used  to  prime 
the  sensor  level  trackers  a  fusion  is  appropriate. 

For  the  standard  Kalman  filter  form.  Equation  (3)  de¬ 
scribes  the  fusion  of  two  updated  sensor  state  vectors  at 
time  t: 

^(0  =  +  [Pi-  Pi2]5"^[^2(0-  ^2(0]  (3) 

where  and  P2  are  the  covariance  matrices  of  the  sen¬ 
sors  and  /’j2  is  the  cross  covariance  matrix  between  the 


sensor  state  vectors,  and  S  the  residual,  as  defined  in 
Equation  (2). 

The  covariance  matrix  P  of  the  fused  estimate  is  given 
by  Equation  (4): 

P  =  P,-  [P^- p^2\S~\Pi- Pnf  (4) 


7  RESULTS 

Experiments  have  been  carried  out  to  evaluate  the  per¬ 
formance  of  a  sensor  level  architecture  for  a  fighter  air¬ 
craft  equipped  with  a  radar,  an  IRST  and  an  ESM.  Addi¬ 
tionally  the  fighter  receives  link  data  from  a  C2  unit,  self 
identification  data  from  network  participants  and  sensor 
data  from  the  network  participants. 

The  hardware  environment  for  the  performance  evalu¬ 
ation  consists  of  a  VAX  computer  for  the  simulation  of 
the  aircraft  model  and  the  sensors,  and  a  commercial 
VME  board  equipped  with  a  Motorola  68020/68882 
processor  as  target  hardware  for  the  Sensor  Fusion. 

Two  examples  are  shown,  the  first  describes  the  proc¬ 
essing  for  two  sensors,  each  providing  20  tracks,  which 
is  an  example  for  the  correlation  of  onboard  sensors. 
The  second  depicts  a  situation  of  200  by  200  tracks. 
Such  an  extreme  situation  may  occur  if  all  available 
tracks  within  a  250  km  x  500  km  area  must  be  unified 
onboard  the  fighter. 

Alignment 

A  complete  alignment  of  the  state  vector,  typically 
range,  azimuth  and  elevation  is  used,  and  its  covariance 
matrix,  requires  1  ms  for  the  onboard  sensors  and  2  ms 
for  tracks  received  from  the  data  link.  On  average  60  ms 
are  required  for  the  first  case  and  600  ms  for  the  second. 
A  general  case  was  assumed  where  the  sensors  provide 
track  updates  only,  and  each  sensor  has  different  update 
times.  Therefore  the  time  alignment  of  all  tracks  from 
one  sensor  to  the  update  time  of  the  other  cannot  be  per¬ 
formed. 

Gating  and  Distance  Measure 

For  the  association  a  three-dimensional  pre-gating  test 
and  the  subsequent  calculation  of  a  normalised  distance 
was  considered.  A  complete  operation  requires  up  to 
0.2  ms.  For  the  first  case  up  to  80  ms  and  for  the  second 
up  to  8  s  are  required. 

This  is  a  very  unlikely  situation,  where  all  tracks  belong 
to  the  same  gate.  Any  result  of  the  assignment  would  be 
very  unlikely,  due  to  the  amount  of  the  other  competing 
track  pairs.  Usually  a  1.5  dimensional  pre-gating  test 
sorts  out  80%  to  90%  of  the  track-to-track  pairs,  and  the 
computation  time  is  reduced  to  25  ms  and  2.5  s  respec¬ 
tively. 

Clustering 

Clustering  can  be  accelerated  by  bit  operations  of  the 
processor.  A  rule  of  thumb  is  0.1  ms  processing  time  for 
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one  track  pair.  Therefore  40  ms  and  4  s  must  be  consid¬ 
ered  for  the  two  cases. 

Clustering  is  considered  to  be  relevant  for  the  identity 
fusion,  in  order  to  provide  suitable  subsets  for  identity 
conflict  examination.  For  the  fusion  of  kinematic  data  it 
is  a  candidate  for  omission,  because  most  scenarios  are 
sufficiently  resolved  by  the  pre-gating  function. 

Assignment 

The  assignment  is  based  on  INTEGER  operations.  To¬ 
gether  with  an  overhead  for  the  conversion  of  the  nor¬ 
malised  distance  to  INTEGER  5  [is  for  one  track  pair  is 
a  representative  figure.  For  an  optimal  assignment  40  ms 
and  40  s  processing  time  for  the  two  cases  are  maxi¬ 
mally  required.  With  a  suboptimal  algorithm  the  proc¬ 
essing  time  can  be  reduced  to  6  ms  and  0.6  s  respec¬ 
tively. 

Fusion 

After  a  final  assignment  of  two  sensor  tracks,  the 
kinematic  accuracy  can  be  improved  by  the  fusion  of  the 
track  data.  For  the  calculation  of  the  state  vector  of  one 
track  together  with  the  covariance  matrix  0.5  ms  is  re¬ 
quired.  If  any  track  of  one  sensor  correlates  with  a  track 
of  another  sensor  10  ms  or  100  ms  processing  time  is  re-, 
quired. 

8  CONCLUSION 

The  processing  time  of  the  two  examples  were  up  to 
230  ms  and  up  to  50.7  s.  This  shows  that  the  Sensor  Fu¬ 
sion  of  the  three  onboard  sensors,  each  providing  20 
tracks,  can  be  performed  within  the  typical  update  time 
of  the  sensors.  Additionally  other  fighters,  with  similar 
track  capacity,  can  contribute  their  sensor  tracks. 

Only  the  fusion  of  two  complete  air  pictures  or  the  fu¬ 
sion  of  an  ESM  with  an  extreme  reporting  capability  and 
an  air  picture  cannot  be  performed  in  real  time.  But  this 
assumes  that  all  200  tracks  are  created  at  the  same  time 
and  must  be  fused  instantaneously.  Such  a  scenario  is 
very  unlikely.  Usually  new  tracks  appear  subsequently 
at  low  rates,  and  can  then  be  processed.  For  tracks 
which  are  already  fused  the  association  rate  can  be  low¬ 
ered,  because  it  is  unlikely  that  the  association  result  is 
changed  after  each  track  update. 
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SUMMARY 

The  Department  of  Defense  is  being  driven  to  use 
Commercial  Off-the-Shelf  (COTS)  hardware  and  software  in 
order  to  reduce  the  overly  complex  and  unnecessary  practices 
of  using  military  standards  and  speeifications  while  reducing 
costs.  There  are  a  variety  of  issues  related  to  the  use  of  COTS 
hardware  and  software  components  in  military  avionics 
systems  that  have  an  impact  in  the  architectures.  Avionics 
packaging,  cooling,  networks,  processors,  and  software 
languages  are  just  a  sample  of  the  areas  affected  by  the  use  of 
COTS.  A  number  of  steps  must  be  taken  by  weapon  systems 
managers  to  ensure  they  have  a  strategy  in  place  to  meet  the 
challenges  brought  on  by  COTS  technologies. 

INTRODUCTION 

The  issues  surrounding  the  use  of  COTS  hardware  and 
software  in  military  avionics  systems  resulted  from  U.S. 
SECDEF  William  Perry’s  June  1994  Best  Commercial 
Practices  (BCP)  initiative.  This  initiative  is  aimed  at  reducing 
the  overly  complex  and  unnecessary  practices  (MIL-STDs, 
Specs,  Testing,  etc.)  in  order  to  reduce  the  cost  of  acquiring 
and  supporting  weapon  systems. 

Early  in  1995,  a  group  of  engineers  from  the  Avionics 
Directorate  of  Wright  Laboratory  were  tasked  to  study  the 
implications  related  to  the  use  of  COTS  on  military  avionics 
systems.  A  number  of  companies  in  the  defense  business 
were  visited  in  order  to  get  their  views  on  the  issues  related  to 
the  use  of  COTS  on  military  avionics.  The  companies  visited 
ranged  from  electronic  device  manufacturers,  avionics  houses, 
and  airframers.  A  report  titled:  “Low-Cost  Avionics 
Through  Best  Commercial  Practices”  was  generated 
summarizing  the  results  of  these  visits. 

In  the  area  of  military  avionics,  many  engineers  and  managers 
immediately  equate  the  Perry  BCP  Initiative  to  the  automatic 
use  of  COTS  hardware  and  software,  and  have  begun 
focusing  on  detailed  design  issues  related  to  the  use  of  a 
particular  commercially-available  microcircuit  or  subsystem. 

This  paper  concludes  that  the  use  of  COTS  alone  is  not  the 
answer  to  lower  avionics  systems  life  cycle  cost.  From  an 
avionics  system  perspective,  the  BCP  Initiative  should  be 
viewed  as  a  means  of  enabling  the  maximum  amount  of 
design,  development  and  testing  freedom  possible  in  order  to 
obtain  the  lowest  life-cycle-cost  avionics  products  from  the 
contractor  community.  Other  conclusions  drawn  are:  COTS 
hardware  and  software  will  be  used  on  aircraft,  but  as 


“hybrid”  designs;  (1)  the  BCP  Initiative  supports  our  ultimate 
objective  of  finding  the  lowest  cost  COTS,  Non- 
Developmental  Item  (NDI),  or  low-risk  technology 
combination  capable  of  doing  the  job;  (2)  COTS  products,  by 
themselves,  are  no  panacea  in  solving  the  avionics  cost 
problem  and  the  introduction  of  COTS  products  may  bring  on 
another  set  of  problems.  These  problems  include:  special 
provisions  for  cooling,  COTS  hardware  and  software 
obsolescence,  architecture  changes  to  support  higher 
performance  and  throughput,  design  changes  and  immature 
products  brought  on  by  its  short  time  to  market  cycle,  added 
weight  and  volume,  and  an  excessive  number  of  “commercial 
standards;”  (3)  The  majority  of  COTS  avionics  products  lie  in 
the  digital  “core”  area  which  constitutes  about  1/4  of  the 
avionics  fly-away  cost  of  modern  fighters,  whereas  few 
COTS  products  are  available  for  the  RF  and  EO/IR  sensors, 
which  account  for  over  1/2  of  the  avionics  cost.  Tailoring 
COTS  products,  co-production  on  commercial  manufacturing 
lines  and  providing  the  contractors  the  freedom  to  be  creative 
by  eliminating  unnecessary  constraints  have  much  higher  cost 
saving  potential  than  a  wholesale  shift  to  the  use  of  COTS 
products  alone  without  a  comprehensive  cost/benefit  analysis. 

This  paper  will  address  some  of  the  issues  related  to  the  use 
of  COTS  hardware  and  software  on  military  avionics  and 
their  effect  on  architectures. 

PACKAGING 

The  harsh  operating  environments  of  fighter  aircraft  have  an 
effect  on  the  electronic  packaging  of  avionics  systems.  In  the 
past,  the  full  military  temperature  range  (-55  to  -(-125  °C)  has 
been  required  for  any  piece  of  avionics  that  reside  in  the 
uninhabited  area  of  a  fighter  aircraft  without  really  measuring 
the  actual  temperatures  to  which  the  equipment  will  be 
subjected  during  its  operational  life.  The  same  requirement  is 
imposed  on  most  avionics  development  programs,  even  if  the 
equipment  is  intended  for  a  cargo  aircraft  relatively  benign 
temperature  environment.  This  requirement  alone  has  driven 
avionics  designers  and  manufacturers  to  sometimes  over- 
designing  the  avionics  using  expensive  MIL-SPEC  parts  and 
exotic  packaging  techniques  in  order  to  meet  the  temperature 
requirements.  Realistic  environmental  requirements  are 
needed  to  determine  what  level  of  COTS  packaging  can  be 
used  in  a  particular  application.  Considerable  costs  savings 
can  be  achieved  just  by  relaxing  the  avionics  operating 
temperature  requirements  to  allow  the  designers  to  use  less 
expensive  industrial  grade  or  COTS  parts  in  their  avionics 
designs. 
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There  is  more  to  considering  COTS  than  just  the  simple 
choice  of  COTS  versus  custom  military  parts.  There  are 
various  grades  of  parts  available.  The  most  common  ones 
will  be  discussed:  military,  industrial,  and  commercial.  The 
top  grade  is  the  full  military  part.  It  is  expected  to  operate 
reliably  in  the  harshest  environments,  over  a  temperature 
range  of  -55  to  +125  “C.  Packaged  in  a  hermetic  ceramic- 
encapsulated  package  in  order  to  withstand  high  humidity 
levels.  These  are  the  highest-priced  components,  their  cost 
can  be  2x  to  5x  the  cost  of  a  commercial  equivalent  part. 
They  are  tested  to  the  fullest  extent  by  the  vendor  before  they 
are  released  as  products.  Normally,  they  are  two  or  three 
generations  behind  the  commercially  available  products.  This 
is  due  to  the  fact  that  parts  manufacturers  wait  until  they  are 
getting  a  high  yield  out  of  their  manufacturing  process  for  the 
commercial  parts,  before  they  try  to  qualify  the  parts  for 
military  applications  that  require  the  full  temperature  range 
operation.  The  next  level  is  the  industrial  grade.  These 
components  are  required  to  operate  over  the  temperature 
range  of  -40  to  +85  "C.  These  parts  are  20%  less  expensive  to 
produce  than  the  full  MIL-SPEC  parts  since  testing  is  not  as 
expensive.  Automotive  parts  are  normally  a  subset  of  this 
grade.  The  last  level  is  the  commercial  grade.  These  parts  are 
required  to  operate  from  0  to  +70  “C.  They  offer  major 
advantages  in  cost,  size,  weight,  performance,  and  market 
lead-time;  thus  they  have  attracted  99%  of  worldwide 
microcircuit  sales  and  are  widely  used  in  automotive  and 
computer  applications.  Commercial  grade  parts  are  packaged 
using  plastic  encapsulants  and  are  commonly  referred  to  as 
plastic-encapsulated  microcircuit  (PEM)  or  simply,  plastic 
parts.  Pure  commercial  parts  are  the  most  available  type  and 
almost  all  new  types  of  electronics  parts  and  upgrades  initially 
come  out  as  pure  commercial  parts. 

The  use  of  COTS  parts  for  military  applications  has  been 
avoided  in  the  past  due  to  hermeticity  problems  of  plastic 
parts  which  resulted  in  unreliable  systems.  These  problems 
plagued  plastic  parts  in  the  early  1970’s  but  have  since  then 
been  corrected  for  the  most  part  by  the  use  of  new  molding 
compounds  and  improved  manufacturing  processes.  Many 
recent  studies  have  proved  that  PEMs  are  as  reliable  or  more 
than  ceramic  packaged  devices  easing  the  introduction  of 
PEMs  in  military  applications. 

Operating  environmental  requirements  play  a  crucial  role  on 
the  type  of  electronics  parts  and  packaging  that  can  be  used 
for  a  given  design  and  application.  By  specifying  realistic 
environmental  requirements,  lower  cost  parts,  which  meet 
those  requirements,  can  be  used  in  new  avionics  designs. 
Another  advantage  of  using  COTS  is  the  availability  of  higher 
performance  parts  and  a  larger  user  community. 

The  warranty  for  commercial  components  is  for  operation 
between  0  to  +70  °C  range.  Any  application  that  operates 
outside  this  range  will  void  the  original  manufacturer  warranty. 
A  variety  of  packaging  approaches  can  be  used  to  isolate  the 
components  from  the  harsh  environments.  Exotic  packaging 
technologies  like  liquid  cooling,  thermal  blankets,  or 


environmental  enclosures  are  available  or  emerging  which  can 
isolate  the  components  from  the  outside  environments.  The 
downside  of  these  packaging  technologies  is  their  high  cost. 
High  packaging  costs  can  easily  cancel  the  cost  savings 
achieved  by  the  use  of  less  expensive  industrial  or  commercial 
components. 

The  size  of  the  electronic  modules  is  another  topic  of 
discussion.  The  military  has  tried  to  standardize  their  electronic 
modules  to  the  Standard  Electronic  Module  (SEM)  size  E,  or 
SEM-E.  This  equates  to  roughly  6”  by  6”  of  board  area.  The 
commercial  market  standard  board  size  is  the  6U  VME 
modules,  with  a  roughly  6”  by  9”  board  size  area.  In 
applications  where  an  existing  commercial  circuit  board  can  be 
used,  the  size  difference  between  the  preferred  commercial  and 
military  standards  presents  a  problem.  In  the  older  weapon 
systems  which  use  mostly  %  ATR  size  black  boxes,  the 
transition  to  6U  VME  size  is  relatively  easy,  since  the  circuit 
board  size  is  very  similar.  This  situation  is  different  in  the  case 
of  new  weapon  systems  where  the  SEM-E  size  is  the  standard 
board  size.  At  this  time,  several  trade  studies  are  underway  to 
compare  the  benefits  and  drawbacks  of  using  different 
electronic  module  sizes  for  military  applications  and  what  are 
the  life  cycle  cost  implications  of  both  alternatives.  There  may 
not  be  a  clear  winner  in  this  area  and  a  combination  of 
electronic  modules  sizes  is  possible.  A  hypothetical  scenario 
would  be  to  use  commercial  standard  size  eleetronic  modules  in 
the  core  processor  area  and  SEM-E  size  modules  in  the  RF  area 
of  the  avionics. 

NETWORKS 

A  critical  area  that  needs  careful  attention  during  the  design 
and  development  phase  is  the  networks  area.  They  are  part  of 
the  airframe  infrastructure  and  are  very  costly  to  repair, 
replace,  or  upgrade.  The  problem  is  exacerbated  in  small 
airframes  where  space  is  at  a  premium  and  every  effort  is 
made  to  use  any  available  volume.  This  is  done  most  of  the 
time  by  sacrifieing  the  maintainability  of  the  avionics, 
specially  the  wiring  (networks).  There  are  issues  assoeiated 
with  using  COTS  networks  with  special  purpose  militarized 
avionics,  militarized  networks  with  COTS  avionics,  or  any 
combination  of  these  two  options.  The  different  network 
options  will  have  different  impacts  in  the  avionics 
architecture  of  new  and  legacy  weapon  systems. 

There  are  a  large  number  of  COTS  networks  available  for 
different  eommercial  applications.  The  applicability  of  a 
particular  COTS  network  to  a  specifie  avionies  design  will 
depend  on  the  functionality  required  out  of  the  network.  It  is 
not  always  easy  to  match  the  capabilities  of  a  commercial 
network  with  the  requirements  of  a  military  application.  If 
requirements  and  capabilities  can  be  matched,  the  avionics 
designer  has  to  worry  about  how  stable  the  eommercial 
standard  is  and  what  is  the  expected  life  of  the  commercial 
standard.  In  the  past  commercial  network  standards  were 
very  stable  and  had  a  long  life  expectancy.  This  is  not  true 
for  new  networks  standards  where  there  are  so  many  available 
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and  the  processor  technology  changes  so  fast  that  networks 
are  forced  to  change  in  order  to  keep  up  with  the  new 
technology  or  they  become  obsolete  and  are  replaced  by 
whole  new  designs.  This  fast  pace  of  change  has  a 
tremendous  impact  on  the  decision  to  use  a  commercial 
network  on  military  avionics.  If  a  commercial  network  is 
selected,  there  is  a  high  probability  that  it  will  have  to  be 
upgraded  at  some  point  in  the  life  of  the  system,  which  will 
be  very  costly  if  it  requires  massive  wiring  changes.  The  use 
of  fiber  optic  networks  mitigates  this  risk  because  of  the 
available  bandwidth  in  the  fiber.  Since  fiber  optic  wires  are 
considerable  less  bulky  and  lighter  than  their  copper 
counterparts,  additional  wires  can  be  laid  out  during  the 
manufacturing  of  the  airframe  for  future  use.  The  use  of 
single  mode  fiber  can  provide  enough  bandwidth  for  the 
foreseeable  future,  where  only  the  optical  receivers  and 
transmitters  would  need  to  be  upgraded  to  keep  up  with 
technology. 

The  option  of  using  a  custom  militarized  network  in 
combination  with  COTS  avionics  presents  it’s  own  set  of 
problems.  As  mentioned  earlier,  COTS  hardware  (specially 
processors)  changes  at  a  very  fast  pace  (around  every  18 
months),  so  the  militarized  network  will  become  obsolete  at 
some  point  in  time  during  the  life  of  the  weapon  system 
requiring  costly  upgrades.  Just  as  in  the  devices  area,  it  is 
very  costly  to  develop  a  network  just  for  military 
applications.  The  DoD  needs  to  take  advantage  of  network 
technologies  available  in  the  commercial  world  where  a  large 
user  base  shares  the  development  costs,  making  the  final 
product  less  costly.  As  explained  in  the  previous  paragraph, 
the  problems  related  to  having  to  upgrade  the  networks  in  the 
future  are  mitigated  by  the  use  of  fiber  optics  cables  instead  of 
copper  wires. 

If  a  copper-based  COTS  network  is  going  to  be  used  in  a  new 
weapon  system,  careful  attention  needs  to  be  given  at  the 
location  of  the  wiring  in  the  aircraft  to  facilitate  any  future 
wiring  changes.  An  alternate  approach  is  to  include 
additional  wiring  in  the  original  design  to  facilitate  upgrades. 
This  is  not  easy  to  do  in  most  instances  where  the  avionics  are 
over  their  weight  budget.  The  use  of  fiber  optics  eases  the 
problem  because  of  their  lighter  weight  and  volume. 

The  adoption  of  new  COTS  hardware  for  legacy  systems 
faces  the  same  problem  described  above.  New  high 
performance  processors  having  to  move  data  through  old,  low 
bandwidth  networks  (MIL-STD-1553)  can  create  potential 
bottlenecks.  These  bottlenecks,  limit  the  functionality  that 
can  be  added  through  the  new  processors  or  require  expensive 
wiring  changes  in  order  to  take  full  advantage  of  the  new 
processors.  A  novel  idea  in  this  area  is  to  try  to  use  the 
existing  wiring  (mostly  MIL-STD-1553  twisted  shielded  pair) 
to  implement  a  different  network  protocol  other  than  MIL- 
STD-1553.  Even  though  it  looks  like  a  good  idea,  to  this  day 
this  author  is  not  aware  of  any  successful  attempts.  Other 
alternatives  include  the  use  of  data  reduction  techniques  and 
even  the  encryption  of  data  before  transmission  with 


decryption  at  the  destination  point.  These  alternatives  have 
been  applied  successfully  eliminating  the  need  for  costly 
wiring  changes.  One  disadvantage  of  these  alternatives  is  the 
time  required  to  perform  the  compression  or  encryption 
process. 

OBSOLESCENCE 

One  of  the  areas  causing  major  concern  about  the  use  of 
COTS  is  commercial  electronics  parts  obsolescence.  As  an 
example,  the  average  turn  around  time  for  new  processors  is 
down  to  18  months.  Technology  life  cycles  are  being  reduced 
from  21  years  for  the  Transistor  Transistor  Logic  (TTL)  to 
less  than  9  years  for  Advanced  BiCMOS  Technology  (ABT). 
If  this  trend  continues  we  can  expect  to  see  technology 
families  lasting  only  5  to  7  years  in  the  near  future.  Their  life 
will  be  shorter  than  the  development  cycle  of  a  complex 
weapon  system.  This  presents  a  problem  for  military  systems 
which  are  generally  designed  to  operate  for  a  life  span  of  20 
to  30  years.  A  normal  weapon  system  will  have  to  go  through 
3  or  4  different  technology  families  during  its  life  cycle. 

On  the  other  hand,  if  done  right,  the  use  of  COTS  can 
eliminate  the  need  for  many  of  the  logistic  support 
requirements.  If  the  equipment  is  highly  reliable  and  low 
cost,  only  a  small  number  of  spare  parts  will  be  required  to 
sustain  the  system  in  operation.  Upgrades  could  be  available 
before  any  failures  occur,  eliminating  the  requirements  for  a 
complex  logistics  support  structure.  The  contractors  will  be 
required  to  track  obsolescent  parts  and  develop  strategies  to 
ensure  aircraft  will  continue  to  be  supplied  with  parts 
throughout  the  life  of  the  aircraft.  The  contractor  would  be 
responsible  for  the  configuration  control  and  the  support  of 
the  COTS-based  avionics.  It  would  be  up  to  him  to  upgrade 
his  products  when  they  become  obsolete.  This  requires  a 
constant  small-scale  engineering  effort  to  maintain  a  current 
design  incorporating  the  latest  technologies. 

A  new  paradigm  will  be  defined  in  the  way  we  procure  and 
upgrade  our  avionics  systems  if  we  adopt  the  wide  use  of 
COTS  in  our  avionics  systems.  Instead  of  having  a  major 
avionics  upgrade  program  every  7  to  10  years,  new 
technology  and  functionality  will  be  added  to  the  avionics 
system  as  new  technology  becomes  available  and  is  integrated 
into  the  avionics  system  designs.  The  contractor  responsible 
for  the  system  will  be  responsible  for  ensuring  the  system 
performs  for  as  long  as  he  is  under  contract. 

The  wide-spread  use  of  COTS  devices  in  avionics  designs 
will  require  more  in  the  area  of  obsolescence  management  to 
ensure  that  parts  obsolescence  do  not  become  an 
unmanageable  problem.  The  contractor  must  establish  an 
obsolescence  management  team.  This  team  will  perform 
detailed  obsolescence  management  surveys  of  potential 
suppliers  and  maintain  a  data  base  of  the  latest  survey  results. 
A  single  point-of-contact  for  obsolescence  notification  must 
be  established  at  each  of  the  subcontractors  involved  in  the 
program.  The  team  will  also  monitor  the  life  cycle  ratings  for 
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all  the  active  technologies  being  used  in  the  program.  Taking 
a  pro-active  role  in  the  area  of  obsolescence  management  is 
crucial  for  the  successful  application  of  COTS  in  military 
applications. 

SOFTWARE 

Military  avionics  and  general  COTS  software  applications  are 
very  different.  Commercial  software  companies  generate 
software  specialized  for  consumer  and  other  commercial 
systems,  not  for  military  systems  such  as  weapon  system 
avionics.  For  the  future,  little,  if  any,  embedded  weapon 
system  software  will  be  COTS.  The  functions  performed  by 
the  embedded  software  are  unique  to  the  military.  For 
example,  the  software  allows  pilots  to  destroy  hostile  targets 
and  avoid  destruction  by  the  enemy.  However,  the  use  of 
commercial  standards  is  applicable,  especially  in  the  area  of 
programming  languages,  operating  systems,  and  application 
programming  interfaces. 

The  use  of  the  Ada  language  is  required  by  law  for  DoD 
weapon  systems.  This  is  an  impediment  for  the  widespread 
adoption  of  COTS  for  use  in  new  weapon  systems.  The  Ada 
mandate  requires  any  modification  to  an  existing  weapon 
system  where  more  than  30%  of  the  code  will  be  changed  to 
be  done  in  Ada.  This  provides  an  avenue  for  older  weapon 
systems  requiring  modifications  to  use  commercial  languages 
instead  of  Ada.  In  the  case  of  a  new  weapon  system,  the  Ada 
mandate  applies  since  100%  of  the  software  will  be  generated, 
it  has  to  be  done  in  Ada. 

The  problem  with  Ada  lies  in  the  availability  and  price  of  Ada 
compilers,  as  well  as  software  tools.  Since  the  Ada  language 
has  not  been  widely  adopted  by  the  commercial  market,  Ada 
software  tools  and  compilers  lag  the  hardware  by  as  much  as 
one  year.  Due  to  their  limited  market,  the  cost  can  be  lOx  the 
commercial  equivalent.  The  commercial  standards  for 
software  languages  are  C  and  C**,  their  use  is  widespread  and 
there  are  many  more  software  tools  available  to  the 
programmer.  Even  Ada  programmers  are  hard  to  come  by 
and  retain  since  they  don’t  see  any  future  for  Ada  in  the 
commercial  market  and  they  want  to  stay  current  in  the  latest 
trends  in  the  commercial  market. 

TESTABILITY 

COTS  electronic  parts  in  general  do  not  have  the  levels  of 
testability  and  built-in  test  (BIT)  that  are  available  in  custom 
militarized  electronic  parts.  Some  provisions  exist  for 
testability  of  COTS  at  the  device,  board,  and  system  level,  but 
are  not  adequate  to  meet  the  military  requirements.  In  order 
to  meet  the  more  stringent  military  requirements  for  fault 
tolerance  and  reconfigurability,  high  levels  of  testability  are 
required.  Some  companies  are  adding  special  application 
specific  integrated  circuits  (ASICs)  to  complement  the 
existing  levels  of  testability  available  in  COTS.  Another  way 
to  make  up  for  the  lack  of  adequate  testability  levels  in  COTS 
is  by  performing  some  of  the  testability  functions  in  software. 


which  adds  complexity  to  the  system,  The  solution  seems  to 
depend  on  the  level  of  COTS  being  used.  When  using  COTS 
at  the  component  level,  additional  devices  can  be  added  to 
improve  testability.  At  the  board  and  system  level,  it  is  more 
cost  effective  to  improve  the  testability  by  the  use  of 
additional  software.  Cost,  operational  requirements  and 
maintenance  strategy  will  play  a  role  on  the  amount  of 
testability  that  is  included  in  designs  taking  advantage  of 
COTS  devices. 

THROWAWAY  MODULES 

The  wide  use  of  COTS  in  military  applications  has  the 
potential  for  providing  life  cycle  costs  savings  in  operation 
support  (O&S)  by  allowing  the  use  of  throwaway 
maintenance.  The  process  to  identify  the  candidates  for 
throwaway  maintenance  will  be  the  same  that  is  used  today  to 
determine  the  most  cost-effective  way  to  maintain  an  item.  A 
repair-level  analysis  will  be  conducted  where  factors  like  item 
cost,  predicted  reliability,  repair  cost,  support  equipment 
requirements,  training,  and  transportation  (among  others)  are 
considered  as  part  of  the  decision  process.  The  lower 
procurement  cost  of  COTS,  alortg  with  the  fact  that  the  items 
will  be  upgraded  more  often  than  it  is  done  currently,  and  the 
extensive  use  of  warranties  should  influence  the  repair  level 
analysis  in  favor  of  throwaway  maintenance.  This  can 
translate  into  savings  in  support  equipment,  personnel, 
technical  orders,  and  training  requirements  at  the  depot  or 
contractor  facility.  To  ensure  that  good  items  are  not 
discarded,  the  levels  of  BIT  need  to  be  sufficient  to  identify  a 
faulty  board  with  a  high  level  of  confidence.  The  decision  to 
include  BIT  to  identify  faults  at  the  circuit  level  on  the  board 
will  be  left  to  the  contractor.  It  will  be  their  decision  to  repair 
or  discard  the  boards.  Discarding  the  boards  will  reduce  the 
levels  of  BIT  in  the  boards,  reducing  the  complexity  of  the 
design  and  the  cost. 

SYSTEM  IMPLICATIONS 

A  major  concern  is  that  if  the  use  of  COTS  and  Best 
commercial  Practices  is  taken  to  the  extreme,  the  reduction  in 
contractor  guidance  could  result  in  a  proliferation  of  custom 
avionics  boxes,  electronic  modules,  displays,  etc.  which  will 
create  an  integration  and  maintenance  nightmare,  destroy 
competitive  procurements  and  make  common,  interoperable 
avionics  (exploiting  economies  of  scale)  impossible. 

One  measure  which  has  the  potential  of  reducing  some  of  these 
problems  is  the  use  of  an  Open  System  Architecture  (OSA)  for 
future  avionics.  Definitive  guidelines  of  how  OSAs  will  be 
employed  are  currently  under  review  by  a  DoD  task  force.  The 
OSA  approach  is  aimed  at  ensuring  the  competition  and 
common  avionics,  through  a  readily-available  set  of  system 
specifications  that  provide  adequate  information  to  build 
interface-compatible  hardware  and  software. 

The  use  of  OSAs  presents  its  own  set  of  issues  and  questions. 
Will  the  eventual  OSA  guidelines  require  the  use  of  commercial 
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interface  standards  for  the  network  design?  If  so,  which  ones 
should  be  used  and  should  the  government  play  a  role  in 
determining  which  COTS  standards  should  be  used  or  should 
the  contractor  decide?  What  should  be  the  electronic  module 
size?  Will  detailed  connector  level  standards  be  imposed  to 
achieve  fit  compatibility?  Is  POSIX  the  right  choice  for  COTS 
software  interface  standards  and  when  will  these  standards  be 
finalized  and  accepted  by  the  commercial  community?  Is  a 
hybrid  (mixture  of  COTS  and  custom)  OSA  the  best  choice  to 
meet  the  performance,  reliability,  weight  and  volume  needs? 

The  entire  OSA  issue  is  highly  complex  and  will  require 
significant  work  to  make  it  meaningful.  For  someone  outside 
the  contractor  team  to  be  able  to  build  something  to  operate  in 
the  architecture,  detailed  OSA  specifications  will  be  required. 
For  the  OSA  concept  to  be  useful,  a  complex  build-to 
specification  is  needed  that  provides  all  the  required  information 
that  will  enable  complete  physical,  electrical,  cooling, 
mechanical  mounting,  and  logical  interfacing  compatibility  with 
the  system.  An  important  benefit  of  this  approach  is  that  it 
allows  proprietary  designs  and  manufacturing  methods  to  be 
employed  below  the  Interface  layer.  For  example,  the  design  of 
the  internal  parts  of  the  module  is  not  specified,  nor  is  the  actual 
software  code  provided. 

This  new  approach  to  using  COTS  and  Best  Commercial 
Practices  giving  more  freedom  to  the  system  designer  to  make 
decisions  about  what  will  be  in  the  design  implies  that  the 
Weapon  System  Contractor  will  play  an  even  stronger,  more 
vital  role  than  ever  in  making  design  and  upgrade  decisions 
over  the  life  of  the  weapon  system.  They  will  work  with  the 
avionics  contractors  to  establish  sub-warranties  and  approve 
parts  selection  and  testing  plans.  The  WSC  will  be  ultimately 
responsible  for  configuration  control  and  ensuring  that  COTS 
obsolescence  problems  do  not  occur.  Further,  the  WSC  will 
maintain  the  flow  of  parts  to  and  from  the  field  of  repair.  It  will 
be  the  DoD  responsibility  to  provide  performance  requirements 
early  in  the  program  and  begin  the  warranty  negotiation 
process. 

CONCLUSIONS 


commercial  practices  that  can  be  followed  like  a  recipe. 
There  are  too  many  variables  that  need  to  be  considered  in 
each  particular  case,  which  have  the  potential  for  changing 
the  outcome  of  the  different  trade  studies,  A  life  cycle  cost 
analysis  will  identify  the  potential  cost  savings  of  a  particular 
approach  and  the  phase(s)  where  the  savings  should  be 
achieved  (development,  production,  operation  and 
maintenance). 

The  weapon  systems  procurement  activities  must  avoid 
overspecifying  requirements  and  stop  forcing  MIL-STD 
manufacturing  processes,  100%  parts  screening  and  extensive 
testing.  It  is  incumbent  on  the  procurement  activity  to  state 
up-front  what  the  real  environmental  requirements  are  and  to 
negotiate,  again  up-front,  a  specific  set  of  performance, 
reliability,  weight,  volume,  cost,  etc.  parameters  from  which 
incentivized  warranties  can  be  negotiated.  The  contractors 
involved  will  then  be  given  the  necessary  freedom  to  meet  the 
warranty  agreement  at  the  lowest  cost.  This  is  very  similar  to 
the  way  the  commercial  market  works.  Working  together  as  a 
team,  applying  a  solid  systems  engineering  approach,  will 
facilitate  the  decision  process  during  the  trade  studies  phase 
and  will  ensure  the  best  solution  is  selected  for  each  particular 
application. 
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The  use  of  COTS  in  military  avionics  architectures  has  the 
potential  for  providing  life  cycle  cost  savings  if  a  systems 
approach  is  followed.  It  is  important  to  follow  this  systems 
approach  from  the  early  phases  of  the  COTS  insertion  process 
taking  into  consideration  the  diversity  of  issues  described  in  the 
previous  paragraphs.  Numerous  trade  studies  will  be  required 
in  order  to  realize  life  cycle  cost  savings  by  making  the  right 
decisions  for  a  particular  application.  As  described  in  the 
previous  sections,  the  development  of  a  weapon  system  is  a 
very  complex  endeavor  requiring  expertise  in  a  number  of 
different  areas.  Avionics  architectures  are  the  infrastructure 
of  an  avionics  system  and  the  decisions  made  during  the 
development  of  the  avionics  architecture  will  have  profound 
impacts  on  the  rest  of  the  avionics  system  and  the  avionics 
contribution  to  the  overall  weapon  system  life  cycle  cost. 
There  is  no  exact  method  to  the  application  of  COTS  and  best 
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Summary 

Daimler-Benz  Aerospace  (Dasa)  Military  Aircraft  Division  has 
set  up  an  experimental  avionic  system  with  modular  stmcture 
using  VMEbus  based  hardware  components  and  a  commercially 
available  operating  system  (OS)  as  common  OS.  Since 
commercially  available  realtime  OSs  do  not  fulfil  the 
requirements  for  future  avionic  systems,  ^stem  Management 
Software  (SYMS)  has  been  developed.  SYMS  enables  the 
communication  between  different  processor  modules  and  their 
co-operation.  This  is  the  presupposition  for  fault  management 
and  reconfiguration  management  within  the  whole  core  system. 
The  reconfigurability  of  the  experimental  system  has  been 
demonstrated. 

The  source  code  of  SYMS  has  been  fully  written  in  Ada.  Small 
sized  interfaces  to  the  hardware  and  to  the  OS  support  easy 
adaptation  to  different  environments  of  hardware  and/or  OS. 
Applications  of  the  whole  core  system  are  controlled  separately 
by  SYMS  Tables  ("Blueprints").  The  approach  supports 
developing  portable  and  reusable  application  software. 

The  flexibility  of  SYMS  enables  the  demonstration  of  different 
standards  and  their  capabilities  within  different  integrated 
systems.  Currently,  this  work  is  of  interest  in  view  of  the  Allied 
Standard  Avionics  Architecture  Council  (ASAAC)  demonstration 
programme,  planned  for  the  ASAAC  Phase  II. 

Flight  capable  derivatives  of  the  experimental  system  can  be 
used  in  different  experimental  flight  programmes.  Information 
about  a  modular  computer  to  be  flown  within  an  experimental 
flight  programme  is  presented. 

1  Introduction 

Paragraphs  1.1  and  1.2  may  be  skipped  by  a  reader  who  is 
familiar  with  Modular  Avionics.  Paragraph  2  summarizes  the 
overall  software  concept  as  defined  in  the  "Core  Avionics 
Architecture  Concept  Definition"  III  and  in  the  "Modular 
Avionics  Harmonization  Study"/2/. 

The  experimental  system  is  described  in  section  4.  Details 
about  SYMS  are  contained  in  section  4.1. 

Section  4.2  indicates  the  present  capability  of  this  software, 
informs  about  the  modular  computer  and  summarizes  the  benefit 
of  SYMS. 

A  list  of  abbreviations  is  attached. 


1.1  Why  Modular  Avionics? 

Since  the  goals  and  advantages  of  Modular  Avionics  have 
already  been  described  (see  e.g.  /3/,  /4/),  only  a  short  summary 
of  the  modular  concept  is  given  here: 

Basic  idea  is  the  common  use  of  a  limited  number  of  different 
modular  architectural  elements  within  different  functional  areas 
of  an  avionic  system.  Modularity  concerns  the  hardware  (H/W) 
as  well  as  the  software  (S/W).  The  "inner  areas"  of  an  avionic 
system  -  excluding  specific  sensor  related  parts  and  the 
actuators  -  shall  be  integrated  using  the  defined  limited  number 
of  different  types  of  architecture  elements.  This  area  called  the 
core  area.  The  kernel  within  the  core  area,  as  indicated  in  the 
title,  is  understood  as  an  expandable  part  ("subarea")  of  the  core 
area.  Within  a  modular  integrated  core  area  the  data  and  signal 
processing  (subfunctions)  of  several  avionic  system  functions 
shall  share  a  set  of  common  processors. 

According  to  the  "Modular  Avionics  Harmonization  Study"  111 
future  avionic  systems  shall  have  availabilities  of  150  hours  in 
a  30  days  period,  free  of  maintenance.  This  shall  be  achieved 
by  a  modular  concept  enabling  increased  fault  tolerance  based 
on  reconfigurability. 

Concerning  costs,  the  modular  concept  shall  considerably 
reduce  Life  Cycle  Costs  (LCC)  for  large  fleets  of  A/Cs. 

In  order  to  achieve  all  economical  advantages,  standardization 
is  essential.  -  Continuous  improvement  of  avionic  systems, 
howe\’er,  requires  "open”  standards.  Therefore,  a  harmonized 
modular  architecture  has  to  prove  technological  transparency: 
The  concept  shall  support  adoption  of  new  components  by  easy 
substitution  or  adaptation  of  H/W  and  S/W. 

1.2  Situation  in  Europe 

Modular  avionic  systems  have  already  been  developed  in  the 
United  States  (see  e.g.  /5/)  when  European  companies  were  still 
engaged  in  concept  definitions,  for  example  during  the  study 
"neue  Avionik  Strukturen"  (nAS  Phase  I  and  Phase  II), 
perfomed  in  Germany,  and  during  the  Allied  Standard  Avionics 
Architecture  Council  (ASAAC)  Phase  I  study,  pierfonned  by 
representatives  from  the  United  States  (US),  the  United 
Kingdom  (UK),  France  (F)  and  Germany  (GE).  At  present. 
Modular  Avionics  in  Europe  is  in  a  prototyping  and 
demonstration  phase. 
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The  goal  of  the  ASAAC  study  is  to  define  concepts  for  a  future 
modular  avionics  architecture  with  the  arm  to  arrive  at 
Standardization  Agreements  (STANAGs).  Within  the  frame  of 
the  ASAAC  Phase  I  study,  concepts  for  future  modular  avionic 
systems  have  been  elaborated.  These  are  contained  in  the  "Core 
Architecture  Concept  Definition"  III.  A  brief  summary  of  / 1/  has 
been  published  in  /6/.  Document  III  has  been  harmonized  and 
agreed  upon  by  authorised  representatives  from  the  governments 
and  industries  of  the  US,  UK,  F,  GE  in  1994,  and  it  is  regarded 
as  a  preliminary  basis  for  further  ASAAC  activities.  These 
concepts  will  be  assessed  and  refined  in  a  first  stage  of  Phase  II, 
which  is  presently  in  preparation.  Phase  11  will  be  carried  out 
without  US  paiticipation;  US  industry  is  already  engaged  in  a 
technology  programme  referring  to  the  more  sensor  related  areas 
m.  During  the  second  stage  of  ASAAC  Phase  H,  a  demonstrator 
for  the  core  avionics  architecture  will  be  built. 

Development  activities  have  been  initiated  in  Europe  by 
suppliers  collaborating  with  US  companies  in  order  to  produce 
modular  architectural  elements,  for  example,  Litef  with  TI  and 
VDO  with  Harris  for  data  and  graphics  processor  modules, 
respectively. 

Since  1992  several  European  companies  and  institutes  have  also 
been  involved  in  the  Research  and  Technology  Programme 
No.  4.1  (RTP4.1),  belonging  to  the  Common  European 
Programme  Area  No.  4  (CEPA4)  of  the  European  Co-Operation 
for  the  Long  Term  in  Defense  (EUCLID)  -  briefly  called 
EUCLID  CEPA4  RTP4.1  study  -  with  the  title  "Modular 
Avionics  Harmonization  Study"  111.  This  study  defines  a  future 
architecture  based  on  emerging  technologies.  RTP4.1  is  the 
technological  basis  for  future  activities  concerning  Modular 
Avionics  in  Europe.  -  The  use  of  Commercial-Off-The-Shelf 
(COTS)  components  is  recommended  in  121  as  well  as  in  several 
other  studies  and  in  a  memorandum  of  the  US  Ministry  of 
Defense  /8/. 

In  the  course  of  the  earlier  activities,  experimental  work  has  also 
been  started  at  Dasa,  for  example  investigations  concerning 
cooling  of  modules  191  or  an  optical  backplane  /lO/.  For  earlier 
activities  concerning  Modular  Avionics  (MA)  at  Dasa,  see  also 
I  in.  However,  none  of  these  works  concerned  aspects  of  system 
integration. 

1.3  Tasks  Performed 

In  1993  Dasa  Military  Aircraft  Division  decided  to  perform  the 
following  tasks: 

(i)  Set  up  of  an  experimental  system  for  Modular  Avionics  using 
COTS  components.  This  includes  the  integration  of  a 
reconfigurable  core  avionic  system  kernel  with  modular 
hardware  and  common  system  management  software  and  the 
demonstration  of  the  reconfigurability  of  the  system. 

(ii)  Based  on  this  kernel:  Development  of  a  modular  computer 
for  use  in  experimental  flight  programmes. 

The  first  task  was  performed  in  1993/94  as  a  Dasa  internal 
study,  hereafter  also  referred  to  as  'first  step".  The  second  task 
was  performed  government  funded  in  1995. 


2  S/W  Concept  Defined  in  Basic  Studies 

Figure  1  visualizes  the  S/W  concept  by  means  of  the  three  layer 
S/W  model  as  defined  in  /!/  and  121.  The  figure  shows  three 
main  S/W  layers,  namely 

application  layer, 
operating  system  layer  and 
module  support  layer. 

The  application  layer  comprises  all  functional  avionic 
application  S/W  (indicated  as  white  rectangles)  and  the 
common  system  applications  (medium  shaded  rectangle).  The 
operating  system  layer  (containing  the  OS,  also  drawn  medium 
shaded,  below)  provides  the  applications  with  a  set  of  services 
through  an  interface,  called  "Application  to  Operating  System 
Interface"  (APOS).  The  module  support  layer  (dark  shaded) 
provides  the  OS  with  a  set  of  basic  services  through  another 
interface,  called  "Module  to  Operating  System  Interface" 
(MOS).  In  Older  to  manage  the  actual  system  configuration  the 
common  system  applications  are  provided  with  the  application 
dependent  parameters  by  means  of  the  "Blueprints".  The 
Blueprints  contain  information  about  the  system  design,  system 
configurations  and  applications  reconfigurations,  hence  the 
control  of  system  health  and  fault  management.  The  APOS,  the 
MOS,  the  common  system  applications  and  the  format  of  the 
Blueprints  shall  be  standardized. 

3  The  Experimental  System 

The  demonstration  of  a  reconfiguration  was  defined  as  a 
principle  part  of  the  first  task.  For  this  purpose,  a  small  H/W 
configuration  with  a  single  VMEbus  appeared  to  be  sufficient. 
Reconfigurations  concerning  the  network  shall  be  enabled  later. 

For  the  first  step,  we  have  regarded  the  common  system 
applications  as  a  set  of  basic  services  for  the  whole  core 
system,  analogous  to  those  performed  by  an  OS  in  a  single 
processor  system.  Therefore,  we  have  called  them  new  services, 
and  we  have  allocated  them  to  the  OS,  "below"  the  applications 
(as  shown  in  Fig.  2  -  the  concept  will  be  described  in  paragraph 
4.1.2).  The  arrangement  supports  the  adaptability  to  different 
OS  (see  paragraph  4.1.4). 

3.1  Definitions  and  Basic  Requirements 

Our  experiment  refers  to  the  capability  of  common  S/W  to 
jjerform  basic  functions  within  the  whole  core  area,  supported 
by  a  common  OS.  In  this  context  the  term  "common"  means: 
The  S/W  is  used  by  each  processor  and  it  is  located  on  each 
processor.  The  common  S/W  -  excluding  the  OS  -  was  called 
System  Management  Software  (SYMS).  SYMS  is  divided  into 
the  new  services  and  the  SYMS  Tables.  The  new  services 
correspond  to  a  subset  of  the  common  applications  and  the 
SYMS  Tables  correspond  to  the  Blueprints,  as  defined  in  III 
and  111,  shown  in  Fig.  1. 

The  following  general  requirements  had  to  be  fulfilled: 

StW  Requirements: 

General  Requirements  for  SYMS: 

Use  of  high  order  language  Ada,  H/W  independence, 
reuseability,  portability,  self  testability,  fault  tolerance,  support 


independent  of  hardware 
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Application  to  Operating  System  Interface 

MOS  : 

Module  to  Operating  System  Interface 

Fig.  1:  Software  Architecture  Layer  Modei  as  Defined  in  the  ASAAC  and  EUCLID  Studies 


The  System  Management  Software 


Legend;  System  Control 

(see  Fig.  1) 


—  contents  dependent  on  project  / 
system  applications 


Fig.  2:  Arrangement  of  the  System  Management  Software 
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of  critical  areas,  support  of  hard  real-time  applications;  support 
of  application  testing  and  testing  of  H/W  elements. 

Requirements  for  the  SYMS  Tables: 

All  dependencies  upon  avionic  application  S/W  as  well  as 
on  system  related  applications  (e.g.  design  and 
configurations)  shall  be  controlled  by  the  System 
Management  Tables  or  SYMS  Tables.  These  tables  shall  be 
used  as  input  for  the  new  services.  The  document 
containing  this  information  is  usually  known  as  System 
Control  Document  (SCD). 

Requirements  for  the  New  Services: 

Controlled  by  the  SYMS  Tables,  the  new  services  shall 
support  system-wide  test,  health  management,  fault 
management  and  (re)configuration  management.  They  shall 
neither  depend  on  the  avionic  application  S/W  nor  on  the 
system  design,  system  configurations  or  on  system 
applications. 

H/W  -  SYMS  and  SYMS  -  OS  interfaces: 

"Small"  sized  interfaces  supporting  easy  substitution  of 
H/W  and/or  OS. 

HIW.- 

Modular  stmcture  enabling  development  of  common  S/W  and 
the  demonstration  of  S/W  related  capabilities  of  modular  avionic 
systems, 

3.2  Development  and  Integration 

The  required  S/W  was  not  available.  Hence,  the  major  tasks  to 
achieve  the  first  step  comprised  design  and  development  of 
SYMS.  All  details  concerning  requirements  for  the  modular 
S/W,  its  development,  capabilities,  advantages  and  possible 
applications  are  described  in  section  4.  The  requirements  listed 
in  the  preceding  paragraph  have  been  fulfilled  for  the  first  step. 

SYMS  enabled  the  integration  of  a  reconfigurable  system.  The 
block  diagramme  of  the  experimental  system  is  shown  in 
Figure  3.  The  figure  shows  the  H/W  stmcture  of  the 
experimental  system  as  set  up  in  the  System  Prototyping  Lab 
(SPL)  at  Dasa.  The  experimental  system  consists  of  the  three 
major  blocks  Core  Avionic  System  Kernel,  AlC  simulation  and 
work  station. 

The  work  station  is  used  for  bootstrapping  and  loading,  and  this 
is  performed  via  Ethernet  connection. 

The  block  for  A/C  simulation  is  connected  to  the  kernel  system 
via  System  Bus  Module  and  MIL-BUS  and  comprises 

an  A/C  model  (S/W)  and  a 
cockpit  for  dynamic  flight  simulations. 

The  Core  Avionic  System  Kernel  consists  of  the  architectural 
elements  summarized  in  Table  1,  The  left  column  contains  types 
of  architectural  elements.  Column  2  lists  the  elements  used  for 
integration  of  our  experimental  system.  Brief  descriptions  and 
remarks  are  given  in  the  right  column.  Available  or  procured 
elements  are  written  in  small  lettes.  Developed  elements  are 
written  in  bold  letters. 

The  PIbus  was  simulated  (written  in  Italics  in  the  table),  loaded 
at  run-time.  One  reason  was  to  achieve  compatibility  with  PIbus 
based  modules,  in  case  such  modules  become  available.  The 
technical  reason  is:  The  modular  concept  requires  a  message 


oriented  protocol.  The  VMEbus  protocol  does  not  provide  these 
features,  whereas  the  PIbus  does.  As  a  result,  our  VMEbus 
based  system  logically  works  with  a  PIbus.  However,  an  other 
message  oriented  protocol  can  be  used. 

Communication  between  the  common  applications  on  different 
data  processors  and  system  reconfiguration  has  been  tested  and 
verified. 

3.3  Description  of  Demonstration 

Reconfigurations  have  been  demonstrated  repeatedly.  At 
present,  reconfigurations  of  the  navigation  display  (NAV)  and 
primary  flight  (PF)  functions  can  be  demonstrated.  During 
demonstrations  the  A/C  is  simulated  to  be  "flown"  by  a  "pilot" 
sitting  in  the  "cockpit",  as  shown  in  Figure  3.  The  NAV  display 
and  the  PF  functions  are  "running"  (are  active)  and  data  from 
these  functions  are  shown  on  the  displays. 

The  initial  state,  the  state  before  a  module  fails,  is 
characterized  as  follows:  Both  applications  have  been 
distributed  on  two  modules,  however,  only  one  is  active  on  one 
module.  The  other  application  is  "sleeping",  i.e.  not  totally 
active:  The  module  is  provided  continuously  with  the  relevant 
acmal  status  data  enabling  a  rapid  continuation  of  the 
application  in  case  of  a  failure  ("warm  stand  by"  redundancy). 

A  failure  state  is  simulated  by  switching  off  one  module 
containing  either  the  NAV  or  the  PF  as  active  application.  Then 
SYMS  performs  a  reconfiguration  automatically,  and  after 
reconfiguration  the  system  is  in  a  new,  stable  state.  In  this  state 
the  system  is  able  to  continue  the  interrupted  application. 

The  reconfiguration  takes  less  time  than  the  period  of  a  minor 
S/W  cycle,  as  required  for  the  system  (e.g.  referring  to  the 
modular  computer:  20  ms  for  the  TORNADO).  Therefore,  no 
intenuption  is  visible  on  the  displays. 

Within  the  rather  small  configuration  of  H/W  used,  this  may 
appear  trivial,  and  further  applications  should  be  demonstrated. 
-  However,  our  SYMS  is  already  capable  to  manage  mors 
general  reconfigurations,  in  an  extended  H/W  configuration. 
This  is  described  in  paragraph  4.2.1. 


4  Present  and  Remaining  Benefit 

The  following  sections  contain  a  more  detailed  description  of 
SYMS  in  pragraph  4.1;  its  benefit  and  already  achieved 
capabilities  for  further  applications  are  described  in  the 
paragraphs  4.2.1  and  4.2.2;  a  summary  of  the  advantages  of  the 
SYMS  concept  is  found  in  paragraph  4.2.3. 

Different  H/W  and  different  OS  are  often  used  within  each 
subsystem  of  conventional  avionic  systems.  As  a  consequence, 
their  avionic  application  S/W  comprises  different  sets  of 
functions  containing  different  codes  for  tasks  which  -  in 
principle  -  are  similar.  The  dependence  of  different  sets  of 
application  S/W  on  different  H/W  and  OS  related  environments 
increases  the  amount  of  application  S/W  to  be  developed  and 
maintained.  Furthermore,  these  sets  are  often  also  dependent  on 
different  programmers  or  on  different  programming  teams. 

These  disadvantages  are  reduced  or  avoided  respectively,  by 
means  of  the  modular  S/W  concept  described  below. 


Relevant  Architectural 

Elements  and  Interfaces 
defined  e.g.  in 
/y  and  m 

- 1 - 

I 

1 

1 

Elements  Used  i  Remarks 

1 

1 

1 

Hardware  Expedients 

Available  VMEbus  based  components  and  simulated  PIbus  protocol 

Rack 

VME  frame.  *  As  used  in  the  lab 

. J...  . 

Modules 

1  . . 

Modules  available  in  the  lab,  i  Motorola  VMEbus  based 

representing  Data  Processor  Modules  i  Complex  Instruction  Set  Computer  (CISC)  processor  modules. 

(DPM)  and  Graphic  Processor  i  A  one-to-one  correspondence  to  the  ASAAC  modules 

Modules  (GPM)  i  is  not  required  for  the  first  step. 

1  Other  COTS  or  ROTS  H/W  can  be  used 

. . . .  . . . . . . . . . . . . . 

Networks 

1  . . . . . . 

MIL-STD-1553B  as  1  u,  j  u 

A/C  s  stem  bus  !  available  and  required  tor  an  expenmental  night  application 

system  us 

11  1-  ■  III  !  protocol  as  described  in  1121,  simulated 

V  ^^i^Dus  as  rach  mtemai  i  ..  ^i-ir  i  ■  < 

on  VMEbus,  loaded  at  run-time. 

communication  network  '  ^ ,  .  .  ,  , 

J  Other  message  onented  protocol  can  be  used 

Software 

Available  and  developed  architectural  elements 

Module  Support  Layer 

SYMS  -  HAV  -  Interface  1  Network  suppport  (to  be  regarded  as  part 

TT/.T7  J  J  X  '  1  of  the  MOS;  here:  Adaptation  to  the  VMEbus) 

HAV  dependent  '  ox  ^ 

c  cvru/rc  '  PIbus  simulation  and  a 

part  of  SYMS  |  Special  Device  Driver  for  the  MIL-STD-1553B 

1 

Operating  System 

j  Available  Ada  realtime  executeable  Off-The-Shelf  kernel 

1  from  Ready  Systems.  Other  OS  can  be  used 

APOS 

SYMS  -  OS  -  Interface,  i  OS  dependent  part  of  new  services,  according 

OS  dependent  i  to  /!/  and  121  required  as  part  of  the  APOS, 

part  of  SYMS  1  between  all  applications  and  the  OS 

Common  System 
Applications 

Part  of  SYMS,  1 

1.  ji  J  ti  XX  i_  xM  '  New  services,  according  to /!/ and /2/ required 

handled  as  "attachment"  i  ,  ,  »  x  •  f 

„  1  (at  least  partially)  in  a  layer  above  the  APOS 

of  the  ARTX  i 

.  i. 

Blueprints 

1  . . . . — . . . . . . 

SYMS  Tables  '  system  control  data  as 

1  input  for  the  new  services 

Avionic  Application  S/W 

_  _  _|_  -  -  - 

Navigation  Display  and  1  ^  ^  ^ 

rx  •  T-i-  t-  ^  1  Available  S/W,  used  to  demonstrate  reconfigurations 

Primary  Flight  functions  i 

1 

Table  1 :  Architectural  Elements  Used  for  Integration  of  the  Core  Avionic  System  Kernel  (see  also  Layer  Model,  Fig. 


Fig.  3: 

Block  Diagramme  of  the 
Experimental  System 


Core  Avionic  System  "Kernei" 


Ethernet" 


VMEbus 


-  Displays 


"Cockpit" 


Work  Station 


A/C  Simulation 
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4.1  The  System  Management  Software 

4.1.1  SAV  Requirements 

SYMS  has  been  developed  in  compliance  with  the  following  SIW 
requirements: 

(1)  The  new  services  shall  have  a  generalized  capability  to 
detect  errors. 

(2)  The  new  services  shall  not  depend  on  the  H/W. 

(3)  The  new  services  shall  be  applicable  for  several  system 
applications  within  any  system  configuration  formed  by  the 
H/W  shown  in  Figure  3  and  listed  in  Table  1.  Adaptation 
to  other  H/W  and  OS  shall  be  possible  without  major 
difficulties.  The  new  services  shall  be  able  to  support  the 
management  of  the  application  S/W  in  other  environments 
due  to  H/W  and/or  OS. 

(4)  Different  system  configurations  can  comprise  different 
configurations  of 

H/W  modules, 

application  S/W  modules, 

sjjecial  interface  modules  for  H/W  and  S/W  and 

different  locations  of  the  application  S/W  on  the 

modules. 

(5)  The  SYMS  Tables  shall  be  edited  in  a  fixed  format. 

The  requirements  (1)  and  (2)  and  (3)  enable  and  enforce 
designing  and  coding  of  application  S/W  in  a  flexible,  generally 
applicable  code,  independent  of  any  specific  H/W  related 
requests. 

Each  of  the  possibilities  indicated  in  (4)  and  their  combinations 
describe  different  states  of  the  system.  Each  state  can  be 
represented  by  a  set  or  subset  (table  or  "subtable")  of  data 
within  the  SYMS  Tables.  Subsequent  states  of  the  system  are 
controlled  by  subsequent  tables.  (Therefore  these  tables  have 
been  called  "Blueprints".) 

4.1.2  SYMS  Concept 

Our  concept  is  shown  in  Figure  4.  The  SYMS  is  drawn  grey 
shaded  and  comprises  the  following  major  parts,  as  indicated  in 
the  figure  by  numbers: 

1.  A  layer  serving  as  interface  to  the  OS, 
the  SYMS  -  OS  -  interface. 

2.  The  new  services. 

3.  A  layer  used  as  interface  to  the  H/W, 
the  SYMS  -  H/W  -  interface. 

4.  The  SYMS  Tables. 

The  SYMS  Tables  are  drawn  in  another  ("softer")  shape 
indicating  variable  contents. 

4.1.3  The  New  Services 

The  package  of  new  services  comprises  the  following  functions: 
Input  Converter  (C,  ).• 

Cj  converts  the  received  data  into  the  format  required  by 
each  user  application. 

Output  Converter  ( C^  ): 

Cq  converts  the  outgoing  data  from  the  application  related 
format  into  a  transmittable  format. 


Error  Handler  (ER): 

ER  checks  the  integrity  of  the  system  and  initiates  suitable 
actions  in  case  of  problems.  Using  the  data  in  the  SYMS 
Tables,  ER  can  find  errors  caused  by  exceeding  the  upper 
limits  of  different  resources,  e.g.  due  to  memory,  capacity, 
processing  load  ... 

Message  Manager  (MM): 

The  user  application  provides  to  MM  the  name  of  data  to 
be  transmitted.  By  means  of  the  SYMS  Tables,  MM 
interpretes  interface  control  information  from  the  SYMS 
Tables  and  initiates  further  control  and  actions.  Further 
actions  concern  the 

distribution  of  different  control  data  to  the  other 
services,  such  as  transmission  of  conversion 
commands  for  the  data  of  each  application  to  Q,  and 

Q- 

destination  of  the  data, 

structure  of  the  data, 

route  to  the  subsequent  device. 

Special  Functions  (SF): 

SF  comprises  a  collection  of  functions,  such  as 

system  applications  to  support  the  use  of  the  SYMS 
Tables  concerning  the  installation  of  device  drivers 
to  manage  dedicated  system  H/W  and 

the  reconfiguration  management  functions. 

4.1.4  Interfaces  to  the  HAV  and  to  the  OS 

The  SYMS  -  HAY  -  Interface 

Two  possibilities  of  transfer  to  the  H/W  have  been 
implemented,  a  general  access  and  an  access  via  special  device 
driver  (SDD). 

The  general  access  is  performed  via  controlled  access  to  other 
boards,  containing  the  same  SYMS.  The  data  are  guided  to 
(from)  the  real  H/W 

via  PIbus  Emulation  offering  a  standardized  device 
handler,  providing  a  message  controlled  transmission  of 
the  data  and  subsequent 

adaptation  to  the  H/W  (or  vice  versa  respectively,)  by 
conversion  of  the  PIbus  requirements  to  the  real  bus 
accesses. 

SDD’s  are  required  for  the  integration  of  devices  which  do  not 
provide  the  facilities  to  comply  with  the  H/W  requirements  of 
the  PIbus  protocol,  such  as  handshaking. 

The  SYMS  -  OS  -  Interface 

The  SYMS  -  OS  -  Interface  consists  of  two  small  sized  layers, 
as  shown  in  Figure  4  (indicated  by  number  1). 

The  upper  converts  a  call  from  the  application  S/W  into  an  OS 
call. 

The  lower  layer  is  the  interface  between  the  OS  and  SYMS. 
Here,  the  resulting  OS  function  is  converted  into  a  call  of  a 
SYMS  function. 

An  attachment  of  our  new  services  to  an  existing  OS  seems 
natural  and  logical  since  the  OS  is  responsible  for  their 
administration. 


The  System  Management  Software 


Legend 

System  Management  Software  (SYMS)  System  Control 

1  Connection  to  the  Operating  System 

2  New  Services 

3  Connection  to  the  H/W,  the 
SYMS  -  H/W  -  interface 

4  SYMSTabies 


C  I  Input  Converter 

C  o  Output  Converter 

ER  Error  Handler 


SF  Special  Functions 

SDD  Special  Device  Driver 

MM  Message  Manager 


Fig.  4:  The  System  Management  Software 


SYMS  System  Control  Data  SYMS 

Tables  ^  Tables 

on  Module  1  on  Module  2 


Primary  Control  Flow  for  the  Data  Transport 
From  Application  A  on  Module  1  to  Application  B  on  Module  2,  as  shown  below 


Data  Flow  From  Application  A  on  Module  1  to  Application  B  on  Module  2 


Legend 

System  Control  (Here:  "Leads  the  path"  from  A  to  B.  This  path  is 
dependent  on  system  applications.  A  does  not  need  to  "know"  the  destination) 


Data  Flow 


Primary  Control  Flow  for  Data  T ransport 
Control  Flow  in  Case  of  Errors 


C|  Input  Converter 

Cq  Output  Converter 

ER  Error  Handler 


SF  Special  Functions 

SDD  Special  Device  Driver 
MM  Message  Manager 


Fig.  5:  Control  Flow  and  Data  Flow  During  Data  Transport 
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4.1.5  The  SYMS  Tables 

The  SYMS  Tables  contain  the  whole  System  Control  Document 
(SCD)  and  they  consist  of  the  following  four  major  tables: 

Interface  Control  Document  (ICD ): 

The  ICD  contains  a  description  of  all  data  paths  from  the 
user  apphcation  to  the  "outside  world"  and  vice  versa.  This 
information  concerns,  for  example,  the  location  of  data,  the 
types  of  data,  conversions  to  be  performed.  Data  elements 
of  each  apphcation  are  represented  in  the  ICD  by  different 
entries. 

The  ICD  is  used  by  C,  und  Cq. 

Resource  Tables: 

The  resource  tables  contain  the  information  about  all  types 
of  resources  to  be  used. 

The  resource  tables  are  used  by  MM. 

Configuration  Tables: 

The  configuration  tables  contain 

references  about  the  connections  to  be  enabled  by 
means  of  the  ICD  table  entries,  * 

a  description  of  the  actual  configuration  (actual  state) 
of  the  system, 

system  states  to  be  enabled  by  reconfigurations. 

The  configuration  tables  are  used  by  MM  and  SF. 

Fault  and  Error  Tables: 

The  fault  and  error  tables  contain  a  Hst  of  possible  errors, 
faults  or  other  erroneous  states  to  be  found  and  a  list  of 
consecutive  actions  to  be  initiated. 

The  fault  and  error  tables  are  used  by  ER. 


4.1.6  Description  of  a  Simple  Data  Transfer 

The  co-operation  of  the  new  services  by  means  of  the  SYMS 
Tables  is  indicated  in  Figure  5.  The  figure  indicates  the  paths  of 
control  data  (upper  half)  and  the  data  stream  (lower  half)  during 
data  transfer  from  module  1  to  module  2.  In  the  following  text 
terms  like  "application  A  on  module  1"  or  "module  1, 
application  A"  are  written  as  "A(l)"  ;  "ER  on  module  2"  is 
written  as  "ER(2)". 

The  data  transfer  is  managed  by  the  following  control  flow: 
Control  Flow  on  Module  1: 

A(l)  has  finished  processing  and  sends  to  MM(1)  control 
information  enabling  the  initiation  of  correct  actions. 

MM(1) 

decodes  the  control  information, 

contacts  SF(1)  to  get  the  actual  control  information 
from  the  configuration  tables(l), 

contacts  ER(1)  in  case  an  error  is  detected  and 

hands  over  the  actual  control  information  for  data 
conversion  from  the  ICD(l)  to  Co(l). 

MM(1)  generates  the  information  for  further  routing  of  the 
data  to  be  transported  by  means  of  the  resource  tables(l) 
and  the  configuration  tables(l). 


In  the  meantime,  the  data  stream  has  reached  Co(l)  and  has 
been  converted.  Now  the  data  are  provied/  transmitted  through 
the 

layer  "Simulation  of  Plbus(l)"  and  "Adaptation  to 
the  Hardware(l)" 

network  and  subsequently  through  the 

layer  "Adaptation  to  the  Hardware(2)"  and 
"Simulation  of  PIbus(2)" 

to  C,(2).  This  includes  the  transfer  of  the  control  message, 
routed  to  MM(2). 

Control  Row  on  Module  2: 

MM(2) 

decodes  the  control  information, 

contacts  SF(2)  to  get  the  actual  control  information 
from  the  configuration  tables(2), 

contacts  ER(2)  in  case  an  error  is  detected, 

hands  over  the  actual  control  information  for  data 
conversion  from  the  ICD(2)  to  C,(2). 

Now,  the  data  transfer  will  be  completed:  Ci(2)  converts  the 
received  data  into  the  format  and  structure  required  by  B(2)  and 
finally,  the  data  are  provided  to  B(2). 

4.2  Remaining  Benefit  and  Possible  Applications 
4.2.1  Reconfigurability 

SYMS  supports  a  flexible  system  design.  Any  sequence  of 
reconfiguration  can  be  determined  by  the  SYMS  Tables.  This 
sequence  depends  on  the  priority  of  the  applications  (S/W 
modules),  for  example  on  their  criticality;  and  the  arrangements 
of  the  applications  on  the  H/W  modules  depend  on  the  defined 
priority.  All  this  will  depend  on  mission  profile  of  the  A/C.  The 
applications  can  be  located  several  times  on  different  H/W 
modules.  Different  system  configurations  may  be  preferred  in 
each  mission  phase.  Based  on  the  defined  sequences,  different 
reconfiguration  schemes  may  be  applied. 

The  demonstration  of  a  reconfiguration,  as  described  in 
paragraph  3.3,  shows  only  a  limited  application  of  SYMS. 
Therefore,  in  this  paragraph,  the  preliminary  reconfiguration 
concept  is  described  in  order  to  explain  the  capabilty  of  SYMS 
already  achieved. 

Currently,  in  our  experimental  system,  error  detection  is 
restricted  to  a  basic  check  of  the  presence  or  reaction  of  a 
module  caused  by  errors  due  to  the  bus  protocol.  Fault 
management  concerns  the  analysis  of  faults  concerning 
communication  between  modules,  and  the  error  analysis  is 
restricted  to  the  identification  of  faulty  H/W  modules.  - 
However,  our  SYMS  can  already  contribute  to  increasing 
system  availability.  This  is  shown  by  means  of  an  abstract 
example,  which  might  appear  as  a  play;  but  we  beheve,  such 
concepts  will  be  practicable  und  useful  for  avionic  systems  of 
the  next  generation. 

A  system  consisting  of  five  H/W  modules  and  the  applications 
A,  B,  C,  ...  ,  P,  as  shown  in  Table  2b  on  the  next  page 
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Table  2  a:  Example  1:  Conventional  System  with  3  Modules  -  One  Failure  (on  Module  1) 

Distribution  of  Applications 


Result  Degradation  or  "system  crash"  (dependent  on  distribution  of  applications) 


Table  2  b:  Example  2:  Modular  System  with  5  Modules  -  One  Failure  (on  Module  1) 


Table  2  c:  Example  3:  Modular  System  with  3  Modules  -  One  Failure  (on  Module  1) 


Application  -  Initial  State 


**»♦*(*)  (*)  (*)  (*)  (*)  (»)  (*) 
(*)  (*)  (*)  (*)  (*)*♦**  *  (*)  (>!■) 

(*)  (*)  (*)  n  (*)  (*)  (*)  (*)  (*)  (*)  *  * 


State  After  Failure  of  Module  1  and  Successive  Reconfiguration 


(*)  (♦) 


I 


Result  Full  system  availability  if  modules  2  and  3  will  not  be  overloaded. 
Otherwise:  Degradation.  This  can  be  avoided  by  a  suitable  system  design. 


N 

O 

(*) 

(♦) 

(*) 

(♦) 

(♦)  (♦)  (♦) 


Legend: 

*  Application  is  active;  (*)  Application  is  "sleeping"; 

*  Application  will  be  affected  by  failure  of  module  1  /  has  been  activated  after  reconfiguration  on  other  module 
Module  has  been  logically  disconnected 


Table  2:  System  Availability  in  Case  of  Failures  for  a  Conventional  and  Two  Modular  Systems  (Examples) 
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shall  be  assumed  (example  2  in  the  middle  of  the  table).  The 
first  columns  contain  the  number  of  each  module.  The  location 
of  different  SAV  applications  on  these  modules  is  indicated  in 
the  following  columns.  The  upper  half  of  the  table  shows  the 
initial  state  of  the  system,  and  the  lower  half  shows  the  state 
after  reconfiguration  due  to  a  failure  on  module  1. 

Preliminarily,  we  have  decided  to  locate  each  application  three 
times,  on  three  different  modules  -  as  indicated  by  the  stars  - 
and  we  have  assumed:  All  applications  require  about  the  same 
processing  load  and  all  H/W  modules  are  identical.  (Otherwise, 
another  distribution  of  applications  should  be  applied.)  Our 
concept  shall  be  explained  by  means  of  a  failure  on  module  1, 
and  this  concerns  mainly  the  columns  A,  B,  C  and  D. 

Initially,  each  application  is  active  once  on  one  module.  In  our 
example,  the  applications  A,  B  and  C  are  all  active  on 
module  1,  as  indicated  by  the  underlined  stars.  The  initially 
active  arrangements  have  been  called  first  arrangements  of  an 
application.  Furthermore,  A,  B  and  C  are  also  located  on  the 
other  modules,  however,  "sleeping",  as  explained  in  paragraph 
3.3.  This  is  indicated  by  the  stars  in  brackets.  If  a  first 
arrangement  is  affected  by  a  failure,  the  "sleeping"  arrangements 
are  activated  by  reconfiguration  in  a  sequence  defined  in  the 
configuration  tables.  The  successors  of  the  first  arrangements 
have  been  called  second  (third,  ...)  arrangements. 

For  completeness,  the  presuppositions  are  listed  here: 

a  message  oriented  protocol  shall  be  used, 

errors  of  the  transport  medium  are  excluded, 

the  fault  shall  occur  during  data  or  message  transfer  from 

application  A  on  module  1  to  application  D  on  module  2. 

In  the  following  text  a  term  like  "ER  on  module  2"  is  written 
as  "ER(2)"  and  a  term  like  "application  A  on  module  1"  or 
"module  1,  application  A"  is  written  as  "A(l)". 

The  failure  is  detected  either  by  MM(1)  or  by  MM(2)  and 
"reported"  to  ER(1)  or  ER(2),  respectively.  By  means  of  data 
from  the  ICD  Tables(l  or  2),  ER(1  or  2)  "knows": 


Module  1  and  module  2  -  more  precisely,  A(l)  and  D(2)  -  are 
directly  involved.  Now  ER(  1  or  2)  initiates  a  voting  between 
further  involved  modules.  This  information  is  contained  in  the 
configuration  tables.  Further  involved  are  all  those  modules 
which  are  related  with  these  modules  containing  arrangements 
of  each  application.  In  our  example,  the  modules 

1  and  2  and  3  are  related  due  to  application  A  and 

1  and  2  and  4  are  related  due  to  application  D. 

This  defines  the  two  sets  of  modules  {1,  2,  3}  and  {1,  2,  4). 

A  2  :  1  voting  can  be  performed  by  the  sets  {1,  2,  3}  or  by 
{1,  2,  4}  or  by  both.  The  fault  will  be  located,  and  the 
reconfiguration  can  be  performed.  One  of  the  -  non  faulty  - 
ERs  initiates  the  isolation  of  the  faulty  module.  All  erroneous 
states  and  data  caused  by  the  identified  error  will  be  eliminated. 
The  relevant  SYMS  Tables  on  all  modules  will  be  updated,  and 
the  system  will  continue  in  a  new,  well  defined  and  stable  state. 
After  reconfiguration,  the  system  is  full  available  tolerating  the 
faulty  module. 

Our  fault  management  concept  is  expandable  to  include  further 
system  resources.  The  error  analysis  could  be  refined  in  order 
to  identify  faults  caused  by  application  S/W  modules. 

4.2.2  SYMS  in  HIMA 

The  modular  computer  shall  be  used  in  different  experimental 
flight  programmes.  The  first  configuration,  called  HIMA  (for 
Helmet  Mounted  Display  integrated  Modular  Avionics)  will  be 
used  in  the  Helmet  Mounted  Display  (HMD)  Experimental 
Programme. 

Integration  of  HIMA  is  based  on  the  use  of  the  same  SYMS, 
OS  and  HAV  as  the  experimental  system.  An  extended  SYMS 
will  be  portable  from  the  experimental  system  to  HIMA  at  any 
time,  without  major  difficulties.  A  housing  has  been  built  for 
installation  of  HIMA  into  the  TORNADO  A/C  which  will  be 
used  for  the  HMD  flight  experiments.  HIMA  is  shown  in 
Figure  6. 
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An  improved  experimental  system,  including  an  extended 
SYMS,  and  another  OS,  for  example  a  UNIX  OS  can  serve  as 
basis  for  further  flight  applications. 

4.2.3  Summary  of  Benefit  Due  to  SYMS 

The  costs  for  design,  development,  test  and  maintenance  of  SAV 
have  increased  tremendously  during  the  last  decades,  and  this 
can  be  no  longer  tolerated.  The  modular  S/W  concept  -  as  a 
major  part  of  the  system  concept  -  will  contribute  to  the 
reduction  of  LCC  remarkeably.  The  advantages  and  the  benefit 
of  the  modular  S/W  concept  can  be  summarized  with  reference 
to  SYMS  as  follows; 

The  modular  S/W  concept  with  SYMS  supports 

developing  reusable  application  S/W  which  is  independent 
of  the  H/W,  because  these  dependencies  are  managed  by 
the  SYMS  Tables  and  performed  by  the  new  services. 

reducing  effort  for  design  and  coding  application  S/W 
modules,  as  apart  from  satisfying  common  interfaces, 
programming  is  independent  of  system  design,  system 
applications  and  system  configurations. 

consistency  checking  during  system  design  by  standard 
design  support  tools,  because  the  system  design  is 
controlled  by  the  SYMS  Tables,  and  these  are  written  in 
a  standard  format. 

testing  application  S/W  due  to  the  reduced  number  of 
different  interfaces. 

system  testing  and  system  verifying  with  a  reduction  in 
the  number  of  different  test  facilities,  and  the  SYMS 
Tables  can  be  tested/verified  separately. 

maintaining  S/W  due  to  the  more  unifomi  design  and  the 
reduced  number  of  different  maintenance  tools. 

S/W  upgrading/extending  by  substitution/adding  of  S/W 
modules. 

redesigning  existing  systems  and  designing/updating  new 
systems. 

Considering  the  amount  of  common  S/W  required  on  each 
module  and  the  several  ("warm  stand  by")  redundant 
arrangements  of  applications,  these  advantages  have  to  be 
balanced  against  an  increased  demand  for  storage  capacity, 
administration  effort  and  reduced  system  performance.  However, 
these  disadvantages  will  become  less  important,  since 

the  S/W  applications  -  and  this  is  the  major  part  of  aU 
S/W  -  do  not  need  to  perform  administration  functions, 
because  these  are  performed  by  the  SYMS, 

H/W  modules  with  a  much  higher  performance  and  with 
increasing  storage  capacity  are  expected  to  be  available  in 
the  future, 

the  price  for  H/W  modules,  hence  for  storage  capacity,  is 
still  decreasing, 

a  conventional  (non  modular)  concept  will  not  allow  the 
redistribution  of  application  S/W  on  different  H/W 
modules  within  the  whole  core  system. 

Therefore,  we  believe:  With  a  practicable  effort,  only  the 
modular  concept  will  enable  the  achievement  of  the  required 
system  availability  of  150  hours  in  a  30  days  period,  free  of 


maintenance. 

It  is  a  long  way  to  the  fully  standardized  Modular  Avionics. 
The  development  of  SYMS  is  an  important  first  step. 

5  Results  and  Conclusions 

Our  concept  is  a  suitable  approach  towards  integration  of  future 
core  avionic  systems.  An  extendable  package  of  System 
Management  Software  has  been  developed.  The  SYMS  Tables 
and  the  new  services  comprise  fully  portable  S/W.  The  concept 
enforces  and  supports  the  development  of  portable  and  reusable 
application  S/W. 

SYMS  should  be  extended  and  qualified  for  use  in  future 
upgrade  programmes. 

The  flexibility  of  our  SYMS  -  OS  and  SYMS  -  H/W  - 
interfaces  is  an  important  feature  in  view  of  the  ASAAC 
demonstration  programme;  The  adaptability  will  support  the 
integration  of  other  H/W  and/or  OS.  This  will  allow  the 
demonstration  of  capabilities  of  different  architectural  elements 
and  standards. 

On  the  other  hand,  as  long  as  the  new  standards  are  not 
established,  the  concept  allows  the  development  and  integration 
of  reconfigurable  systems,  based  on  COTS.  System 
qualification  should  be  based  on  a  qualified  extended  SYMS 
and  on  qualified  Ruggedized-Off-The-Shelf  (ROTS) 
components.  System  test  will  be  facilitated  by  means  of  a 
refined  SYMS. 

Similar  approaches  should  be  considered  for  application  in 
other  future  aerospace  systems. 
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Abbreviations 

A(n) 

Application  S/W  module  A,  located  on  H/W 
module  n,  n  =  1,  2,  3,  ... 

APOS 

Application  to  Operating  System  Interface 

ARTX 

Ada  Real  Time  Executable  Run  Time  System 
(COTS  OS  from  Ready  Systems) 

ASAAC 

Allied  Standard  Avionic  Architecture  Council 

A/C 

Aircraft 

CEPA 

Common  European  Programme  Area 

c. 

Input  Converter 

Co 

Output  Converter 

C I  /  0 

Input  Converter  or  Output  Converter,  located  on 
H/W  module  n,  n  =  1,  2,  3,  ... 

asc 

Complex  Instmction  Set  Computer 

COTS 

Commercial-Off-The-Shelf 

Das  a 

Daimler-Benz  Aerospace 

debis 

Daimler-Benz  Inter  Services 

DPM 

Data  Processor  Module 

ER 

Error  Handler 

ER(n) 

Error  Handler,  located  on 

H/W  module  n,  n  =  1,  2,  3,  ... 

EUCLID 

European  Co-Operation  for  the  Long  Term  in 
Defense 

F 

France 

GPM 

Graphic  Processor  Module 

GE 

Germany  or  German 

HIMA 

Helmet  Mounted  Display  Integrated  Modular 
Avionics 

HMD 

Helmet  Mounted  Display 

H/W 

Hardware 

ICD 

Interface  Control  Document 

LCC 

Life  Cycle  Cost 

LME 

Luftfahrt,  Mditarische,  Entwicklung  (  development 
department  of  Dasa  Military  Aircraft  Division) 

MA 

Modular  Avionics 

MIL 

Military 

MM 

Message  Manager 

MM(n) 

Message  Manager,  located  on 

H/W  module  n,  n  =  1,  2,  3,  ... 

MOS 

Module  to  Operating  System  Interface 

MULTICS 

Multiplexed  Information  and  Computing  Service 

nAS 

neue  Avionik-Strukturen  (GE  study  programme) 

NAV 

Navigation  Function  (S/W  application) 

OS 

Operating  System 

PF 

Primary  Flight  Function  (S/W  application) 

PI 

Parallel  Interface  or  Processor  Interface 

RTP 

Research  and  Technology  Programme 

ROTS 

Ruggedized-Off-The-Shelf 

SCD 

System  Control  Document 

SDD 

System  Device  Driver 

SF 

Special  Functions 

SF(n) 

Special  Functions  on  module  n,  n  =  1,  2  ... 

SPL 

System  Prototyping  Lab  (at  Dasa  LME  in  Munich) 

STANAG 

Standardization  Agreement 

SYMS 

System  Management  Software 

SYMS(n) 

SYMS,  located  on  H/W  module  n,  n  =  1,  2,  3,  ... 
H/W  module  n,  n  =  1,  2,  3,  ... 

S/W 

Software 

UK 

United  Kingdom 

UNICS 

Uniplexed  Information  and  Computing  Service 

UNIX 

(see  UNICS;  Bell  Labs  trade  name  for  a  system 
derived  from  MULTICS  and  UNICS) 

US 

United  States  (of  America) 

VME 

Versatile  Module  Europe 
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by 
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Daimler-Benz  Aerospace  Airbus  GmbH,  Hamburg 
Kreetslag  10 
P.O.  Box  95  01  09 
21129  Hamburg 
GERMANY 


SUMMARY 


There  is  a  need  for  a  new  military  transport  aircraft, 
which  can  cope  with  the  operational  requirements  to 
improve  the  current  airtransport  forces  of  the  European 
countries  to  satisfy  tactical,  logistic  and  future  opera¬ 
tions,  at  the  beginning  of  the  next  century. 

Significant  requirements,  which  relate  to  the  avionics 
and  mission  systems,  are  for  instance: 

0  low-level  flight  capability  and 

o  board-autonomous  approach  and  landing 

capability 

enabling  adverse  weather  operations  by  day  and  night. 

This  paper  describes  a  system  concept  for  low-level 
flight  capability  based  on  commercial  avionics  as  used 
in  AIRBUS  aircraft.  First,  the  essential  functions  and 
features  of  the  flight  control  and  flight  guidance  system 
are  highlighted.  Then,  the  additional  functions  and  sy¬ 
stem  elements  related  to  controls/displays  and  operatio¬ 
nal  modes,  which  are  required  for  low-level  flight,  are 
discussed.  Finally,  the  first  results  of  a  demonstration 
and  pilot  evaluation  performed  in  the  flight  simulator  at 
DAIMLER-BENZ  AEROSPACE  AIRBUS  in  Hamburg 
are  presented. 

The  investigations  described  in  this  paper  have  been 
performed  within  the  context  of  technology  studies, 
which  are  partially  sponsored  by  the  German  Ministry 
of  Defence. 


LIST  OF  ABBREVIATIONS 


FCS 

Flight  Control  System 

FCU 

Flight  Control  Unit 

FD 

Flight  Director 

FMS 

Flight  Management  System 

FPA 

Flight  Path  Angle 

ft 

feet 

GNSS 

Global  Navigation  Satellite  System 

HDD 

Head-Down  Display 

HUD 

Head-Up  Display 

IRS 

Intertial  Reference  System 

LDG 

Landing 

L/G 

Landing  Gear 

MCDU 

Multipurpose  Control  and 

Display  Unit 

MSA 

Minimum  Sector  Altitude 

MSL 

Mean  Sea  Level 

ND 

Navigation  Display 

PFD 

Primary  Flight  Display 

RA 

Radio  Altitude 

SCH 

Set  Clearence  Height 

TOC 

Top  of  Climb 

TOD 

Top  of  Descent 

TOW 

Take-off  Weight 

1.  DEFINITION  OF  "LOW-LEVEL  FLIGHT" 

Flights  are  defined  as  "low-level",  when  performed  with 

0  jet  aircraft  below  1  500  ft  above 
ground  level  (AGL) 

0  propeller  aircraft  or  helicopters 
below  500  ft  AGL. 


AFCS 

Autoflight  Control  System 

AGL 

Above  Ground  Level 

AOA 

Angle  of  Attack 

AP 

Autopilot 

ATHR 

Autothrust 

BARF 

Basic  Airworthiness 

Requirements  File 

EFIS 

Electronic  Flight 

Information  System 

FbW 

Fly-by-Wire 

Low-level  flights  are  performed  for  reasons  of  self¬ 
protection  against  threats  (e.g.  hostile  sensors  or  anti¬ 
aircraft  defence)  by  means  of  terrain  masking.  In  fact 
low-"level"  flight  profiles  are  trajectories  representing  a 
combination  of  terrain-following  and  terrain/threat-avoi¬ 
dance  segments. 

But  there  are  also  important  low-level  applications  out¬ 
side  hostile  environment,  as  for  instance,  assistance  or 
emergency  flights  (e.g.  para-dropping  in  low-ceiling 
weather  conditions). 


Paper  presented  at  the  AGARD  MSP  Symposium  on  “Advanced  Architectures  for  Aerospace 
Mission  Systems”,  held  in  Istanbul,  Turkey,  14-17  October  1996,  and  published  in  CP-581. 
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2.  FLIGHT  GUIDANCE  SYSTEM  OF  A 
COMMERCIAL  AIRCRAFT 

The  realization  of  the  future  military  transport  aircraft 
wilt  be  performed  correspondent  to  a  commercial  appro¬ 
ach.  This  means,  for  instance,  that  the  aircraft  design  is 
based  on  the  Basic  Airworthiness  Requirements  File 
(BARF)  and  AIRBUS  rules,  completed  by  additional 
military  requirements.  Therefore  it  is  necessary  to  in¬ 
vestigate  the  suitability  of  commercial  avionics  to  cope 
with  the  operational  requirements  ("dual  use"). 

The  flight  guidance  system  of  a  modem  commercial 
aircraft  consists  of  the  following  major  components: 

0  Electronic  Flight  Control  System 

(Fly-by- Wire  -  FbW) 

0  Autoflight  Control  System  (AFCS) 

0  Flight  Management  System  (FMS) 

0  Flight  Guidance  Information  (Primary  Flight 

Display  -  PFD,  Navigation  Display  -  ND) 

0  Navigation  Sensors. 

These  components  form  three  control  loops  as  shown  in 
Figure  1. 


According  to  the  operational  mode  selected  by  the  crew 
the  aircraft  can  be  piloted  either  manually  via  the  Fly¬ 
by-Wire  System,  or  temporarily  automatically  during 
certain  flight  phases  via  the  Autoflight  Control  System 
or  completely  automatically  during  the  whole  flight  via 
the  Flight  Management  System. 

2.1  Fly-by-Wire  System  (FbW) 

An  Electronic  Flight  Control  System  (Fly-by- Wire)  can 
be  characterized  by  the  following  features: 

Pilot's  control  inputs  are  transmitted  by  means  of  elec¬ 
trical  signals.  Flight  control  computers  transform  the 
control  inputs  into  control  surface  commands.  The  flight 
control  computers  also  contain  stabilization  functions,  as 
for  instance: 

o  Auto  Trim 

The  Auto  Trim  function  keeps  the  commanded 
load  factor  (flight  path  angle)  constant  and 
adjusts  the  angle  between  elevators  and  vertical 
stabilizer  to  zero. 

0  Turn  Compensation 

The  Turn  Compensation  function  keeps  the 
flight  path  angle  constant  during  turns. 


FIGURE  1:  Components  of  a  Modern  Commercial  Flight  Guidance  System 
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0  Turn  Coordination 

The  Turn  Coordination  function  permits  a  slip- 
free  flight,  i.e.  turns  don‘t  need  to  be  supported 
by  peddal  commands. 

0  One  Engine  Out  Compensation 

When  an  engine  failure  occurs,  this  function 
prevents  from  unintended  yawing  of  the  air¬ 
craft. 

0  Yaw  Damping 

to  control  the  aircraft's  own  dynamic  modes. 

Additionally  the  flight  control  computers  contain  mo¬ 
nitoring  functions  (envelope  protections)  to  keep  the 
aircraft  within  its  operational  limits.  These  are: 

0  High  Angle  of  Attack  Protection 

For  low-speed  flight  phases  the  angle  of 
attack  (AOA)  will  be  kept  below  the  stall 
range. 

0  Maneuver  Protection 

For  reasons  of  structural  integrity  the  comman¬ 
ded  load  factor  (vertical  acceleration)  will  be 
kept  within  the  permissible  range. 

o  Overspeed  Protection 

An  excessive  high-speed  condition  might  result 
in  structural  failure  or  loss  of  control  due  to 
high  air  loads,  vibration,  flutter  or  shock 
waves.  The  aircraft  ist  protected  from  entering 
an  excessive  high-speed  flight  regime  by  an 
automatic  thrust  reduction  and  an  initiation  of  a 
climb  (positive  load  factor  command). 

o  Attitude  Protection 

This  protection  prevents  the  aircraft  from  achi¬ 
eving  excessive  pitch  and  roll  attitudes. 

2.2  Autoflight  Control  System  (AFCS) 

The  Autoflight  Control  System  (AFCS)  consists  of  the 
components: 

o  Autopilot  (AP) 

o  Autothrust  (ATHR) 

0  Flight  Control  Unit  (FCU). 

The  Autopilot  contains  functions,  which  permit  to  guide 
the  aircraft  along  selected  courses  and/or  at  selected 
altitudes  and  to  perform  climbs,  descents  or  approaches. 

The  Autothrust  (ATHR)  functions  permit  to  keep  selec¬ 
ted  speeds  or  thrust  levels. 


The  nominal  values  of  the  corresponding  flight  para¬ 
meters  can  be  provided  in  two  different  ways: 

o  Manual  selection  via  the  Flight  Control  Unit 
(FCU)  "Selected  Guidance". 

0  Provision  of  nominal  values  by  the  Flight  Ma¬ 
nagement  System  (FMS)  "Managed  Guidance". 

The  aircraft  can  be  piloted  either  automatically  ("AP 
Engaged")  or  manually  ("AP  Disengaged")  on  the  basis 
of  Flight  Director  (FD)  information,  i.e.  indicated 
commands,  which  are  provided  by  the  Autopilot. 

The  FD  information  is  displayed  on  the  Primary  Flight 
Display  (PFD). 

2.3  Flight  Management  System  (FMS) 

The  essential  elements  of  a  Flight  Management  System 
are: 

o  Flight  Management  Computer  including  Navi¬ 
gation  Data  Base  and  Performance  Data  Base 

o  Multipurpose  Control  and  Display  Unit 

(MCDU)  for  data  input. 

Two  FMS  functions  are  important  with  respect  to  flight 
guidance  (Figure  2): 

o  Flight  Planning 

-  Flight  Plan  Stringing 

-  Performance  Calculation 

o  Flight  Plan  Execution 

-  Navigation 

-  Vertical  Guidance 


2.3.1  Flight  Plan  Stringing 

The  (horizontal)  flight  route  between  departure  and 
destination  airports  has  to  be  constructed.  For  this  pur¬ 
pose  airline  defined  company  routes  or  route  elements, 
e.g.  runways,  airways,  nav  aids,  waypoints,  etc.  are 
available  in  the  navigation  data  base. 
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FIGURE  2:  Flight  Management  System  (FMS)  Functionality 


2.3.2  Performance  Calculation 

The  vertical  flight  profile  is  calculated  taking  into  ac¬ 
count  the  following  parameters: 

o  Take-off  Weight  (TOW) 

0  Air  Data  (Wind,  Temperature)  of  candidate 

flight  levels 
o  Cost  Index 

The  cost  index,  which  in  commercial  air 
transport  is  determined  individually  by  each 
airline,  is  the  optimization  criterion. 

Results  of  the  performance  calculation  are  (optimum): 


0  Automatic  radio  frequency  tuning 

0  Determination  of  track,  distance  and  flight  time 
between  waypoints 

0  Determination  of  target  headings/tracks  as  input 
to  the  Autopilot  function. 

2.3.4  Vertical  Guidance 

The  tasks  of  the  Vertical  Guidance  function  are  similar 
to  those  of  the  Navigation  function,  however  related  to 
the  vertical  plane.  Addtional  tasks  are: 


o  Cruising  Altitudes 

0  Cruising  Speeds 

0  Vertical  Speeds  and/or  Flight  Path  Angles. 


0  Determination  of  distance  and  flight  time  to 
pseudo  waypoints  (Top  of  Climb  -  TOC  and 
Top  of  Descent  -  TOD) 


2.3.3  Navigation 

The  Navigation  function  includes  the  following  tasks: 

0  Determination  of  the  "best"  present  position  on 
the  basis  of  all  available  sensors’  data 
(air,  inertial,  radio  navigation,  GNSS) 


0  Determination  of  target  speeds  and  target  thrust 
settings  as  input  to  the  Autothrust 
function. 

The  information  provided  by  the  FMS  (e.g.  flight  plan, 
present  position,  tracks,  distances  and  flight  times  to 
waypoints)  is  presented  on  the  Navigation  Display 
(ND). 
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3.  MISSION  PHASES 

A  military  transport  mission  consits  like  a  commercial 
flight  of  the  following  mission  phases: 

Take-off,  climb,  cruise,  descent,  approach,  landing  and 
perhaps  go-around.  Special  flight  phases  in  this  context 
are  low-level  segments,  which  can  be  considered  as  part 
of  the  cruising  phase,  and  the  board-autonomous  lan¬ 
ding  at  the  end  of  a  low-level  segment. 

The  various  flight  profiles  Including  low-level  segments 
are  normally  planned  in  advance  of  a  mission  taking 
into  account  the  tactical  situation. 

In  special  situations  (like  detection  of  unexpected  thre¬ 
ats)  the  aircraft  has  to  deviate  from  pre-planned  routes. 
Such  situations  require  the  capability  of  guiding  the 
aircraft  back  to  a  planned  route  as  well  as  the  capability 
of  an  onboard  "on-line"  re-planning  of  flight  profiles. 


3.1  Low-level  Flight  Segments 

Low-level  flight  segments  are  integral  elements  of  a 
planned  mission.  A  low-level  flight  profile  is  defined  by 
three-dimensional  (3D)  waypoints,  of  which  the  vertical 
coordinates  are  referenced  to  ground  (AGL). 


During  the  transition  phase  between  cruising  flight  level 
and  low-level  segments,  required  systems  checks  are 
conducted.  If  all  sensores  and  systems  involved  are 
operating  normally  the  low-level  flight  phase  can  be 
initiated.  The  vertical  reference  is  switched  from  "Baro" 
to  "AGL". 

In  case  of  deviation  from  a  planned  flight  profile  the 
aircraft  is  vertically  guided  to  a  "Minimum  Sector  Alti¬ 
tude  (MSA)"  to  be  clear  of  terrain.  For  a  return  to  the 
planned  flight  profile  the  aircraft,  first,  is  horizontally 
guided  back  to  the  track  at  MSA,  then  being  on  track, 
the  aircraft  will  follow  the  vertical  profile. 

The  low-level  flight  segment  is  shown  in  Figure  3. 

3.2  Board-Autonomous  Landing 

Board-Autonomous  or  self-contained  landing  means 
landing  without  ground-based  support  by  radio  naviga¬ 
tional  aids  and  without  standard  approach  procedures, 
which  permit  defined  aircraft  configuration  changes 
from  cruise  to  landing. 

Board-autonomous  landing  capability  requires  in  addi¬ 
tion  to  a  self-contained  precision  navigation  an  energy 
management  function,  which  determines  the  required 
configuration  changes  of  the  aircraft  along  any  given 
flight  profile. 

The  board-autonomous  landing  procedure  is  shown  in 
Figure  4. 


TOD  TOC 


FIGURE  3:  Transfer  Phase  between  Cruising  Flight  Level  and  Low-Level  Flight  Segments 
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FIGURE  4:  Board-Autonomous  Landing  Procedure 


4.  RESULTING  REQUIREMENTS  RELATED  TO 
THE  FLIGHT  GUIDANCE  SYSTEM 

Low-level  flight  and  board-autonomous  landing  capa¬ 
bilities  require  some  modifications  and  additions  to  the 
functionality  of  a  commercial  flight  guidance  system, 
which  are  described  below. 


4.1  Fly-by-Wire  System 

The  Flight  Control  System  (FCS)  of  the  future  military 
transport  aircraft  will  be  based  on  the  FCS  features  of  a 
commercial  aircraft. 

Structure  and  functionality  of  a  civil  FbW-System  can 
largely  be  transferred.  Control  laws  will  have  to  be 
adjusted  to  the  performanee  (size,  weight  and  installed 
agility)  of  the  aircraft. 


4.2  Autoflight  Control  System 

4.2.1  Autopilot 

The  functionality  of  a  civil  AP  can  also  be  transferred. 

Two  significant  functions  have  to  be  added: 

0  Function  "Route"  performs  the  guidance  along 
the  planned  horizontal  route  based  on  the  para¬ 
meters  "Track"  and  "Lateral  Deviation  (Cross- 
Track  Error)". 

0  Function  "Profile"  performs  the  guidance  along 
the  planned  vertical  profile  on  the  basis  of  the 
parameters  "Flight  Path  Angle"  and  "Vertieal 
Deviation". 


4.2.2  Autothrust 

The  Autothrust  functions  of  a  commercial  AFCS  have 
to  be  modified  in  the  following  way: 

0  Speed/Maeh  function  has  to  be  adjusted  to  the 

higher  flight  dynamics  of  the  aircraft. 

0  Thrust  function  has  to  be  extended  in  a  way, 
which  permits  to  set  any  defined  thrust  level. 
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4.3  Flight  Management  System  The  vertical  low-level  flight  profile  is  generated  auto¬ 

matically.  A  Trajectory  Computation  function  determi- 

4.3.1  Flight  Planning  nes  all  parameters,  which  define  the  (4D)  trajectory. 

These  are: 

Planning,  modifications  and  re-planning  of  flight  pro¬ 
files  have  to  be  possible,  during  the  mission  onboard  o  Vertical  coordinates  of  the  waypoints 

the  aircraft  by  the  flight  crew. 

0  Connecting  straight  lines  between  3D  way- 
A  digital  map  containing  geographical,  aeronautical  and  points 

tactical  information  is  displayed  on  a  Touch  Screen 

Device,  i.e.  a  Liquid  Crystal  Display  (LCD)  with  a  o  Transition  arcs  (horizontal  and  vertical)  bet- 

touch-sensitive  surface  (Figure  5).  ween  the  straight  lines 

On  the  basis  of  this  information  the  operator  can  ma-  o  Tracks,  distances  between  waypoints  and  times 

nually  insert  waypoints  via  the  Touch  Screen.  The  FMS  over  waypoints. 

determines  the  connecting  straight  lines  (tracks)  between 

the  waypoints  and  the  transition  arcs  between  the  tracks 

resulting  in  the  horizontal  (2D)  route  (Figure  6). 


FIGURE  5;  Flight  Planning  by  Means  of  Touch  Screen  Device 


FIGURE  6:  Manual-Interactive  Horizontal  Flight  Route  Planning 


The  resulting  (4D)  trajectory,  which  is  checked  for 

o  Obstacle  and  threat  clearance 

0  Aircraft  performance 

0  Continuity, 

is  called  "Flight  Plan"  and  will  be  stored. 

4.3.2  Flight  Plan  Execution 

After  activation  of  a  fight  plan,  the  actual  aircraft  posi¬ 
tion  will  be  related  to  the  nominal  (4D)  trajectory. 
Deviations  and  target  values  will  be  determined  concer¬ 
ning: 

o  Track  (horizontal  route) 

0  Flight  path  angle  (vertical  flight  profile) 

0  Thrust 

as  input  for  the  Autopilot  and  Autothrust  functions. 


For  board-autonomous  landing,  additionally  a  "landing 
window"  will  be  determined,  to  control  the  optimum 
aircraft  configuration  change  between  (low-level)  "crui¬ 
se"  configuration  and  "landing"  configuration  and  to 
issue  commands  for  settings  of  flaps,  speed  brakes  and 
landing  gear. 

4.4  Flight  Guidance  Information 

For  low-level  flights  the  Head-Up  Display  (HUD)  re¬ 
presents  the  Primary  Flight  Display  (PFD).  The  sym¬ 
bology  used  (Figure  7)  has  been  derived  fi-om  the  PFD 
format  of  an  EFIS  (Electronic  Flight  Information  Sy¬ 
stem).  Besides  the  so  called  "Basic-T"  information  (atti¬ 
tude,  speeds,  altitude  and  heading)  Pitch  and  Bank  com¬ 
mands  (Flight  Director  information)  are  presented.  Ad¬ 
ditionally  command  indication  for  manual  Thrust  Set¬ 
ting  (Thrust  Director  information)  is  provided. 
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FIGURE  7:  Head-Up  Display  (HUD)  Symbology 


5.  RESULTS  OF  FIRST  PILOT  EVALUATIONS 

Demonstrations  and  first  pilot  evaluations  have  been  The  flight  guidance  information  presented  on  both  HUD 

performed  in  the  flight  simulator  at  DAIMLER-BENZ  und  HDDs  (PFDs  and  NDs)  was  also  well  accepted  and 

AEROSPACE  AIRBUS  in  Hamburg.  The  results  ob-  permitted  a  precise  and  comfortable  piloting  of  the 
tained  so  far  were  very  promising.  The  handling  of  the  aircraft  along  planned  flight  profiles, 
aircraft  during  low-level  flight  conditions  was  very 

satisfactory.  The  operational  modes  and  the  correspon-  The  investigations  have  shown  that  low-level  capabili- 
ding  transitions  between  automatic  and  manual  opera-  ties  of  a  military  transport  aircraft  can  well  be  achieved 
tion  was  well  accepted.  with  commercial  avionics. 
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SUMMARY 

This  paper  discusses  a  method  to  help  in  the 
selection  of  a  software  developer  by  performing 
in-plant  capability  reviews.  The  present  trend 
not  to  use  government  standards,  necessates  the 
careful  review  of  a  contractor’s  capability  and 
present  development  process. 

Introduction. 

Software  represents  a  major  portion  of  most 
modem  weapon  systems.  Even  though  its 
duplication  cost  is  very  small  compared  to  the 
production  cost  of  system  hardware,  its 
development  cost  can  exceed  50  percent  of  the 
system  development  cost.  A  seemingly  minor 
failure  in  software  can  cause  total  system 
failure.  Since  software  is  only  present  in 
conceptual  form,  other  than  the  ones  and  zeros 
stored  in  program  memory,  inspection  to 
determine  quality  and  consistency  is  very 
difficult.  It  is  far  more  life  cycle  cost  effective 
to  design  and  develop  quality  software,  with  few 
if  any  errors,  than  to  try  to  find  and  fix  errors 
after  the  software  is  developed. 

Table  1  shows  data  from  a  validated  model  by 
Krasner  of  Lockheed  indicating  the  cost, 
schedule,  and  expected  error  rates  for 
developers  at  various  levels  of  maturity  as  rated 
by  the  Software  Engineering  Institute’s  (SEI) 
Capability  Maturity  Model  (CMM)^^^ .  Each 
project  was  500  Thousand  Source  Lines  of  Code 
(KSLOC).  The  model  was  validated  by 
comparison  with  actual  project  data. 


Table  1  shows  immediately  the  return  on 
investment  for  process  improvement  for  the 
developer  and  the  value  for  the  customer  in 
reduced  defects.  The  cost  reduction  would  be  a 
significant  benefit  for  fixed  price  contracts,  but 
it  might  be  considered  a  negative  to  a  cost-plus 
contractor. 

The  U.S.  and  NATO  governments  have  taken  a 
great  interest  in  ensuring  that  software  suppliers 
improve  the  way  that  they  develop  software. 
These  efforts  have  taken  many  forms.  ISO 
9000  may  be  used  as  a  basis  for  software 
process  improvement'^^^  along  with  other 
methods  discussed  here.  A  primary  effort  in  the 
U.S.  has  been  the  use  of  DOD-STD  2167A, 
Defense  System  Software  Development, 
where  a  systematic  process  for  software 
development  is  spelled  out,  along  with 
descriptions  of  the  products  expected  at  the  end 
of  each  phase  of  development.  Application  of 
this  standard  allowed  knowledgeable  customer 
software  engineers  to  observe  and  “audit”  the 
development  processes.  These  audits  often  took 
the  form  of  document  reviews. 

The  added  interest  in  software  quality  by  the 
customers  and  the  hope  of  reduced  development 
cost  caused  many  software  developers  to  search 
for  process  improvements.  The  Software 
Engineering  Institute  (SEI)  at  Camege  Mellon 
University,  funded  by  the  U.S.  Department  of 
Defense  (DOD),  has  been  one  of  the  leaders  in 
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32-2 


providing  software  process  improvement 
information  and  measurement.  The  SEI 
Capability  Maturity  Model  (CMM)  is  now 
widely  used  by  companies  to  perform  self- 
assessment  to  measure  their  capability  and  how 
it  has  changed  with  process  improvement.  The 
SEI  also  promotes  the  use  of  Software 
Engineering  Process  Groups  that  lead 
communication  of  process  improvement 
activities. 

The  U.S.  DOD’s  decision  to  eliminate  most  of 
the  military  specifications  has  changed  the 
methods  for  selecting  and  dealing  with 
computer  software  development  contractors. 
Previously,  on  development  contracts  where 
DOD-STD-2167A  was  used,  the  Government 
customer  was  able  to  review  and  approve  each 
deliverable  document  that  represented  the 
requirements,  design,  or  testing  before  the  next 
phase  of  the  project  could  begin.  While  this 
review  gave  the  customer  control  over  project 
direction,  reductions  in  the  number  of  trained 
Government  software  engineers  often  created 
delays  in  the  approval  process.  Contractors 
producing  software  were  then  forced  to  proceed, 
assuming  that  approval  would  be  forthcoming. 
The  problems  that  followed  caused  the  actual 
software  product  to  be  disconnected  from  the 
requirements  and  design  documentation  that 
were  supposed  to  be  the  product’s  source 
components. 

With  this  removal  of  DOD  military  standards 
and  acquisition  streamlining  staff  reductions,  it 
is  necessary  to  totally  rely  on  the  developer  who 
must  check  the  accuracy  of  requirements 
analysis,  designs,  integration,  and  testing.  Two 
techniques  have  been  used  to  try  to  make  this 
approach  work.  The  first  approach  is  to  use 
Government  software  engineers  working  as 
team  members  with  the  developer  in  integrated 
product  teams  (IPT)  rather  than  as  auditors  or 
reviewers,  as  was  once  the  case.  These 
Government  IPT  members  facilitate 
communication  between  the  contractor  and  the 
final  customer  (user).  The  second  approach  is  to 


implement  the  source  selection  process  to 
carefully  select  a  developer  who  has  the 
capability,  capacity,  experience,  and  software 
development  process  in  place  to  produce  the 
required  high  quality  software  without  intensive 
oversight.  Often  both  techniques  are  used  on 
projects  where  the  software  contribution  to  the 
system  will  be  critical. 

While  it  has  always  been  desirable  to  select  a 
capable  contractor,  several  impediments  for 
intelligent  selection  have  existed  in  the  past. 
One,  software  engineering  is  a  relatively  new 
discipline  and  there  are  still  different  views  of 
software  processes.  Two,  procurement 
regulations  have  emphasized  fairness  in 
evaluating  the  current  proposal  to  the  extent  that 
some  past  problems  with  a  contractor  might  not 
be  considered  in  award  determination. 

Performance  Based  Evaluations 

The  U.S.  Air  Force  Aeronautical  Systems 
Center  (ASC)  recognized  that  while  companies 
were  involved  with  software  process 
improvement,  contracts  were  with  individual 
groups  within  the  company.  Few,  if  any, 
companies  are  homogeneous  in  their  software 
development  procedures.  To  evaluate  the 
capability  of  individual  project  groups,  ASC 
produced  the  Software  Development 
Capability/Capacity  Review  (SDCCR)^^^ .  The 
system  has  now  been  expanded,  with  the  aid  of 
corporate  participants,  to  include  systems 
engineering  capability  and  has  been  renamed  as 
the  Software  Development  Capability 
Evaluation  (SDCE).^®’ 

The  SDCE  augments  software  process 
improvement  as  a  more  specific  tool.  A 
company  can  use  the  CMM  to  establish  its 
process  improvement  plan  and  can  be  assessed 
against  the  CMM  to  show  progress.  Individual 
contract  efforts  then  use  the  SDCE  to  evaluate 
proposed  implementation  groups.  The  SEI  has 
also  developed  a  Software  Capability 
Evaluation  (SCE)^^^  to  perform  group 
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evaluations.  While  capability  reviews  are 
generally  performed  by  the  procuring  agency, 
they  may  also  be  used  by  the  development 
contractors  for  practice  or  to  test  their  own 
status.  In  these  cases  it  may  be  desirable  to  use 
an  independent  person  who  has  capability 
evaluation  experience. 

An  often  used  method  for  performance 
evaluation  is  past  performance  on  completed  or 
nearly  complete  contracts.  In  this  method,  the 
customers  on  previous  projects  report  problems 
as  well  as  accomplishments  on  the  project.  This 
method  is  quite  valuable  in  determining  if  a 
contractor  has  a  major  flaw  in  his  development 
process.  However,  it  has  some  difficulties  for  a 
competitive  procurement: 

•  Since  different  customer 
representatives  are  reporting  for  each 
offeror,  the  evaluations  can  be  biased 
by  that  reporting  person’s  attitude. 
That  attitude  for  the  contractor  can 
range  from  hate  for,  to  impending 
hire  by  the  subject  company. 

•  Completed  contracts  are  seldom 
identical  in  complexity.  A  contractor 
that  has  problems  performing  on  a 
difficult  contract  might  actually  be 
more  capable  than  one  who  shows 
good  performance  on  a  simple 
contract. 

•  If  incomplete  data  are  available  on 
past  performance,  the  team 
evaluating  the  data  tends  to  use  its 
own  experience  with  proposing 
contractors  as  data  inputs.  This 
again  raises  the  opportunity  for 
unequal  evaluations. 

•  In  rapidly  changing  technology  such 
as  software  development,  a 
contractor’s  capability  on  a  project 
delivered  several  years  ago  may  be 
totally  out  of  date  with  current 
capability. 


Each  of  these  problems  may  reduce  the 
objectivity  and  fairness  of  a  contractor  selection. 
However,  there  is  a  strong  case  for  rewarding 
capable  contractors  and  avoiding  those  who  do 
not  have  or  have  not  had  sufficient  capability  to 
perform. 

In-Plant  Capability  Evaluations 

Both  the  SDCE  and  the  SCE  depend  on  in-plant 
evaluation.  By  taking  a  qualified  team  into  each 
proposing  plant,  one  can  get  current  and 
accurate  data  that  eliminate  the  problems  just 
mentioned: 

•  By  using  the  same  identical  team  to 
visit  each  contractor,  the  capability 
measurement  is  calibrated  to  the 
same  evaluator  baseline.  Problems 
with  positive  or  negative  biases  of  a 
single  individual  should  be  addressed 
whenever  they  appear,  but  should  be 
solved  before  visits  start.  The  use  of 
a  standard  set  of  questions  and  an 
accepted  set  of  answers  also  ensures 
equal  treatment  for  all  prospective 
contractors. 

•  The  in-plant  review  evaluates  how 
current  projects  are  being  executed. 
The  review  team  should  search  for  a 
range  of  projects  that  include  the 
expected  complexity  of  the  new 
project.  If  no  projects  of  a  similar  or 
more  complex  nature  can  be  found  at 
a  contractor,  then  limited  capability 
may  be  assumed.  The  team’s 
judgment  is  important  in  issues  such 
as  this;  this  emphasizes  the  necessity 
for  using  a  team  that  is  not  only 
expert  in  software  development  and 
systems  engineering,  but  also  very 
experienced  in  capability  reviews. 

•  Incomplete  data  that  lead  to  input 
from  evaluator  experience  is 
unlikely,  since  each  contractor  is 
visited  to  obtain  data. 
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•  Since  the  past  performance  data  are 
taken  from  stages  of  projects  that  are 
in  current  development  or  just 
completed,  the  contractor  is  given 
credit  for  recent  process 
improvement  activity.  Most 
software  development  process 
improvement  for  U.S.  contractors 
has  peaked  in  the  last  several  years. 

The  question  is  often  asked,  “Why  not  just  let 
the  prospective  contractors  submit  a  written 
description  of  their  development  process?”  This 
technique  would  produce  a  less  than  accurate 
picture  of  the  current  state  of  practice  at  a  given 
location.  There  is  a  tendency  to  acknowledge 
what  one  should  do  even  if  they  are  not  doing  it. 
Most  developers  acknowledge  some  software 
development  methodology  that  would  produce 
quality  code,  but  human  nature  is  to  respond  to 
schedule  and  budget  pressures  to  take  short  cuts 
or  eliminate  critical  steps.  Other  organizations 
may  go  so  far  as  to  hire  an  outside  (outside  the 
group  or  outside  the  company)  individual  to 
write  the  software  development  plan  for 
proposal  submission. 

Even  in-plant  briefings  can  be  misleading  if 
verification  of  the  current  process  is  not 
observed.  On  one  visit  by  the  authors,  the 
quality  assurance  manager,  who  also  controlled 
configuration  management,  gave  an  excellent 
discussion  of  an  automated  system  for  detecting 
change  activity  so  that  he  could  be  aware  of  new 
code  to  be  analyzed  and  archived.  The  software 
engineers  commented  that  with  this,  he  became 
a  very  effective  watchdog  to  ensure  that  they 
followed  the  company  procedures.  At  the 
request  to  see  q  demonstration  of  this  tool, 
neither  the  quality  assurance  manager  nor  the 
project  softs^are  leader  could  log  into  the 
system.  The  review  team  concluded  that  the 
system  was  not  as  widely  used  on  that  project  as 
had  been  indicated. 

The  purpose  of  in-plant  reviews  is  not  to  verify 
that  one  particular  methodology  is  being  used, 


but  that  a  reasonable  methodology  that  fits  the 
development  organization  is  in  consistent  use. 
One  of  the  most  often  used  complaints  about 
DOD-STD  2167A  was  that  in  requiring  the 
waterfall  methodology,  it  made  object-oriented 
development  much  more  difficult.  However, 
consistency  is  necessary  to  improve  a  process. 

If  a  process  is  not  consistently  followed, 
measurements  or  making  changes  to  improve  it 
will  produce  inconclusive  results. 

At  this  time  two  different  in-plant  evaluation 
methods  are  in  general  use  by  the  USAF.  The 
SEI’s  SCE  based  on  the  CMM  is  preferred  for 
evaluation  of  ground  based  and  intelligence 
systems  and  AFMC’s  SDCE  is  preferred  for 
embedded  and  airborne  systems. 

SDCE 

Air  Force  Material  Command  Pamphlet  63-103 
states  the  primary  purpose  of  the  SDCE  is  to 
“increase  the  probability  of  selecting  an  offeror” 
(proposing  contractor)  “capable  of  successfully 
developing  software  to  meet  request  for 
proposal  (REP)  requirements.”  It  is  intended  to 
identify  strengths  and  weaknesses  of  an  offeror 
and  not  to  establish  a  single  digit  rating. 

The  evaluation  is  based  on  six  functional  areas: 

•  Program  Management 

•  Systems  Engineering 

•  Software  Engineering 

•  Quality  Management  And  Product 
Control 

•  Organizational  Resources  And 
Program  Support 

•  Program  Specific  Technologies. 

Each  of  these  functional  areas  are  supported  by 
critical  capability  areas  (CCA).  Figure  1 
shows  the  relation  of  CCA’s  to  the  functional 
areas. 

The  CCAs  are  farther  delineated  as  individual 
capability  items  in  the  SDCE  rnodel.  Each 
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individual  capability  item  has  at  least  one 
question  developed  to  help  understand  the 
offeror’s  capability.  Table  2  shows  typical 
critical  capability  items  and  the  related 
questions.  The  Cl,  C2  etc.  refer  to  capability 
items,  and  Ql,  Q2,  etc.  refer  to  questions. 

The  SDCE  method  is  flexible  in  that  each 
project  considering  the  purchase  of  software  can 
tailor  the  question  to  be  asked  by  selecting  those 
CCAs  that  are  applicable  to  that  project.  The 
number  of  questions  asked  for  each  CCA  may 
also  be  reduced  to  fit  the  size  and  complexity  of 
the  intended  contract. 

The  outline  of  questions  typically  used  for 
embedded  weapon  system  applications  follows: 

1 .  Program  Management. 

1.1  Management  Authority, 
Responsibility,  and  Accountability 

1 .2  Program  Planning  and  Tracking 

1 .3  Subcontractor  Management 

1 .4  Risk  Control 

2.  Systems  Engineering. 

2.1  System  Requirements  Development, 
Management,  and  Control 

2.2  Computer  System  Architecture 
Design  and  Review  Process 

2.3  Supportability 

2.4  Intergroup  Coordination 

2.5  Systems  Engineering  Planning 

2.6  System  Integration  and  Test 

3.  Software  Engineering. 

3.1  Software  Development  Planning 

3.2  Software  Project  Tracking  and 
Reporting 

3.3  Software  Requirements  Management 

3.4  Software  Design 

3.5  Software  Coding  and  Unit  Testing 

3.6  Software  Integration  and  Test 

4.  Quality  Management  and  Product  Control. 

4.1  Software  Quality  Management 

4.2  Software  Quality  Assurance 

4.3  Defect  Control 

4.4  Metrics 

4.5  Peer  Reviews 


4.6  Internal  Independent  Verification 
and  Validation  (IIV&V) 

4.7  Software  Configuration  Management 

5.  Organizational  Resources  and  Program 
Support. 

5.1  Organizational  Standards  and 
Procedures 

5.2  Facilities 

5.3  Training 

5.4  Human  Resources 

5.5  System/Software  Engineering 
Environment 

6.  Program  Specific  Technologies.  Questions 
are  added  here  if  particular  unique  expertise  or 
facilities  are  required.  Such  as,  expert  systems, 
fuzzy  logic,  large  scale  geographic  data  bases, 
etc. 

Review  Team  Selection 

Since  the  purpose  of  the  review  team  visit  is  to 
understand  and  evaluate  the  offeror’s 
capabilities,  the  expertise  and  experience  of  the 
team  is  paramount.  Review  teams  vary  in  size 
depending  on  the  size  and  complexity  of  the 
project.  Experience  has  shown  that  a  team  of 
three  to  four  individuals  is  acceptable  if  at  least 
two  of  the  individuals  are  very  experienced  in 
software  engineering  and  have  experience  in 
capability  reviews.  An  ideal,  small  team  might 
consist  of: 

•  A  leader  with  10-15  years  both  in 
systems  and  software  engineering 
and  experience  leading  several 
SDCE’s. 

•  A  senior  software  engineer  with  1 0 
or  more  years  of  software 
engineering  experience  and 
experience  participating  on  several 
capability  reviews. 

•  A  software  engineer  with  5  or  more 
years  of  software  engineering 
experience. 

•  A  systems  engineer  from  the  project 

•  A  specialty  engineer  from  the 
project. 
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It  is  wise  to  continue  to  include  new  individuals 
on  the  teams  at  the  third  and  fourth  positions  to 
provide  training  and  experience  for  them  to  later 
take  the  leader  positions. 

Experience: 

More  than  25  in-plant  visits  have  been 
conducted  by  the  authors  in  the  last  two  years. 
Generally  these  have  been  in  support  of  a  souree 
(contractor)  selection.  However,  since  an  in- 
plant  review  reveals  weakness  as  well  as 
strengths  of  a  development  organization,  several 
reviews  have  been  condueted  for  developments 
in  progress  that  were  experiencing  difficulties. 
This  latter  type  of  review  is  often  referred  to  as  a 
“Red  Team  Review.” 

Visits  supporting  Eglin  programs  were 
accomplished  with  a  team  that  normally 
consisted  of  four  engineers,  but  the  number 
varied  from  three  to  five.  To  show  complete 
impartiality  and  fairness  on  reviews  for  source 
selection  purposes,  the  same  exact  team 
composition  and  list  of  questions  were  used  for 
all  visits  related  to  that  particular  source 
selection. 


The  types  of  organizations  reviewed  included 
eommercial  contractors  (both  prime  contractors 
and  subcontractors),  U.S.  Military  software 
developers,  and  development  activities  outside 
the  U.  S. 

Reviews  were  found  valuable  in  pointing  out 
strengths  in  partieular  eontractor’s  capabilities 
that  could  be  used  in  recommendations  to  the 
official  determining  the  winning  contraetor. 
Specific  strengths  commonly  found  among 
contractor  groups  with  a  high  capability 
included; 

•  Continuing  effort  to  improve  the 
method  (process)  for  developing 
software. 


•  Established  methodology  with  an 
ongoing  enhancement  plan. 

•  Common  collection  of  tools  for 
project  adoption. 

•  Meaningful  training  program  on 
methodology  and  tools. 

•  Employee  support  for  the  adopted 
process  and  its  improvement. 

•  Colleetion  and  use  of  meaningful 
metrics. 

Specific  weaknesses  among  low  capability 
company  groups  included: 

•  Little  management  interest  in  process 
improvement. 

•  Ad  hoc  selection  of  methodology 
and  random  adherence  to  it. 

•  Tools  selected  by  individual 
developer,  if  available  at  all. 

•  Minimal  training  effort. 

•  Employee  resistance  to  process 
improvement,  if  it  existed. 

•  No  easy  way  to  determine  progress 
in  improving  development. 

It  should  be  noted  that  two  individual  groups 
within  the  same  corporate  division  can  fall  into 
different  capability  groups.  This  fact 
strengthens  the  case  for  reviews  of  individual 
development  groups  rather  than  relying  on  a 
single  rating  of  a  company  or  large  division. 

Conclusion 

In  plant  capability  reviews  have  been  found  to 
be  an  effective  way  to  indicate  strengths  and 
weaknesses  of  potential  software  developers.  It 
is  a  time  efficient  method  that  can  be  completed 
well  within  the  time  that  other  source  selection 
factors  are  being  evaluated.  In  its  structured 
format  each  potential  developer  is  treated 
equally.  This  helps  to  eliminate  protests  from 
those  evaluated. 


CMM  LEVEL 
1 
2 
3 


DEFECTS/KSLOC 

>8 


COST 

DEVELOPMENT  TIME 

$33  M 

40  MONTHS 

$15  M 

32  MONTHS 

$7M 

25  MONTHS 

$3  M 

19  MONTHS 

$1  M 

16  MONTHS 

TABLE  1.  CMM  LEVEL  vs.  COST 

(Crosstalk  Jan  1993)  (Krazner/Lockheed  study) 


2  Systems  Engineering 

2.1  System  Requirements  Development,  Management  and  Control 

2.1.1  Development  and  Allocation  of  Requirements 


C1  A  systems  analysis  and  allocation  process  is  used 
to  verify  that  the  performance  and  verification 
requirements  are  correct  and  complete  at  each  level 
prior  to  further  allocation  and  decomposition,  and  to 
verify  them  as  to  feasibility  and  top-level  design 
concept  prior  to  allocation  to  software.  Q1 

C2  The  selected  systems  analysis  and  allocation 

methodology  is  compatible  with  other  methodologies 
adopted  on  the  program.  Q2 

C3  System  requirements  (including  test  and  verification 
requirements)  are  analyzed,  refined  and 
decomposed  to  assure  complete  functional 
allocation  to  hardware  and  software.  Q3 

C4  When  a  system-level  requirement  is  allocated  to 
more  than  one  configuration  item  (Cl),  a  process  is 
used  to  assure  that  the  lower-level  requirements 
taken  together  satisfy  to  the  system-level 
requirement.  Q4 

C5  A  defined  process  is  used  to  generate  the  initial 
versions  of  the  Software  Requirements 
Specifications  (SRS)  and  the  Interface 
Requirements  Specifications  (IRS).  A  process  to 
develop  and  review  verification  requirements  for 
each  performance  requirement  is  in  place.  Q5 

C6  A  process  exists  to  identify  all  design  documents, 
requirements  specifications,  and  interface 
specifications  across  the  development  team, 
including  subcontractors.  Q6 


Q1  How  are  system  and  subsystem  requirements 
defined  and  allocated?  How  are  these 
requirements  verified  at  each  level  prior  to  further 
allocation  and  decomposition?  How  are  those 
requirements  that  imply  digital  processing  and 
software  verified  as  to  feasibility  and  top-level 
design  concept  prior  to  allocation  to  software?  C1 

Q2  Describe  how  the  systems  analysis  and  allocation 
methodology  is  compatible  with  the  systems 
design  methodology,  and  with  the  soWare 
analysis  methodology?  C2 

Q3  Describe  the  process  by  which  system 
requirements  are  analyzed,  refined  and 
decomposed  to  develop  a  functional  allocation  to 
hardware,  software,  and  other  implementation 
technologies.  Describe  the  process  and  specific 
trade  studies  and  analyses  performed  to  aid  in 
deciding  which  requirements  to  allocate  to 
hardware  and  which  to  software.  C3 

Q4  Describe  the  process  which  assures  that  when  a 
system-level  requirement  is  allocated  to  more  than 
one  configuration  item  (Cl),  the  combination  of  the 
lower-level  requirements  meets  the  system-level 
requirement.  C4 

Q5  Describe  the  process  that  is  used  to  generate  the 
Software  Requirements  Specifications  (SRS)  and 
Interface  Requirements  Specifications  (IRS). 
Describe  the  process  to  define  verification 
requirements  for  each  performance  requirement  as 
part  of  the  requirements  and  definition 
(specification  preparation)  process.  C5 


(From  AFMC  Pamphlet  63-103) 


TABLE  2.  EXAMPLE  QUESTIONS  FOR  SDCE 


_ FA  1.0 _  _ FA  2.0 _  _ FA  3.0 _  _ FA  4.0 _  FA  5.0  FA  6,0 

PROGRAM  SYSTEMS  SOFTWARE  QUALITY  ORGANIZATIONAL  PROGRAM 

MANAGEMENT  ENGINEERING  ENGINEERING  MANAGEMENT*  RESOURCES*  SPECIFIC 

_  _  _  PRODUCT  CONTROL  PROGRAM  SUPPORT  TECHNOLOGIES 
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FIGURE  1  SDCE  MODEL 


[1]  Over,  J.W.,  “Motivation  for  Process-Driven 

Development,”  CrossTalk,  Journal  of  Defense 
Software  Engineering,  Volume  40,  January  1993, 
pp.  17-24. 

[2]  Paulk,  M.,  Curtis,  B.,  Chrissis,  M.,  and  Weber,  C., 

“Capability  Maturity  Model  for  Software,  Version 
1.1,”  Technical  Report  CMU/SE1-93-TR-024, 
Pittsburgh,  1989. 

[3]  Stelzer,  D.,  Mellis,  W.,  and  Herzwurm,  G., 

“Software  Process  Improvement  via  ISO  9000? 
Results  of  two  surveys  among  European  software 
houses,”  IEEE  Proceedings  of  the  29th  Hawaii 
International  Conference  on  Systems  Sciences, 
Volume  1,  January  1996,  pp.  703-712. 

[4]  U.S.  Department  of  Defense,  “DOD-STD-2167A, 

Defense  System  Software  Development,  ”  February 
1988. 

[5]  U.S.  AFSC/ASD  “Pamphlet  800-5,  Software 

Development  Capability/Capacity  Review” 
September  1987 

[6]  U.S.  AFMC  “Pamphlet  63-103,  Software 

Development  Capability  Evaluation,”  June,  1994) 

[7]  Byrnes,  P.,  and  Phillips,  M.,  “Software  Capability 

Evaluation  Version  3.0  Method  Description,” 
Technical  Report  CMU/SEI-96-TR-002,  1996 


REPORT  DOCUMENTATION  PAGE 


1.  Recipient’s  Reference 

2.  Originator’s  Reference 

3.  Further  Reference 

4.  Security  ClassiHcation 
of  Document 

AGARD-CP-581 

ISBN  92-836-0044-4 

UNCLASSIFIED/ 

UNLIMITED 

5.  Originator  Advisory  Group  for  Aerospace  Research  and  Development 
North  Atlantic  Treaty  Organization 
7  rue  Ancelle,  92200  Neuilly-sur-Seine,  France 


6.  Title 

Advanced  Architectures  for  Aerospace  Mission  Systems 

7.  Presented  at/sponsored  by 

The  Mission  Systems  Panel  6th  Symposium  held  in 
Istanbul,  Turkey,  14-17  October  1996. 


8.  Author(s)/Editor(s) 

Multiply 


9.  Date 

July  1997 


10.  Author’s/Editor’s  Address 
Multiple 


11.  Pages 
312 


12.  Distribution  Statement  There  are  no  restrictions  on  the  distribution  of  this  document. 

Information  about  the  availability  of  this  and  other  AGARD 
unclassified  publications  is  given  on  the  back  cover. 


13.  Keywords/Descriptors 
Avionics 

Aerospace  engineering 

Computer  architecture 

Weapon  systems 

Integrated  systems 

Economic  factors 

Commercial  equipment 

Commercial  Off-The-Shelf  (COTS) 


Signal  processing 
Data  processing 
T  elecommunication 
Information  systems 
Military  applications 
Surveillance 
Reconnaissance 


14.  Abstract 

This  volume  contains  the  Technical  Evaluation  Report  and  the  30  unclassified  papers,  presented 
at  the  Mission  Systems  Panel  Symposium  held  in  Istanbul,  Turkey,  14-17  October  1996. 

The  papers  presented  covered  the  following  headings: 

•  Invited  Papers; 

•  Military  Applications  of  Civil  Systems; 

•  Communications  (Systems); 

•  Communications  (Technology); 

•  Surveillance  (Reconnaissance); 

•  Surveillance  (Meteorology); 

•  Surveillance  (Early  Warning); 

•  Information  Extraction; 

•  Vehicle  Management; 

•  Future  Systems  and  Panel  Discussion. 


NATO  OTAN 

7  RUE  ANCELLE  •  92200  NEUILLY-SUR-SEINE 


DIFFUSION  DES  PUBLICATIONS 
AGARD  NON  CLASSIFIEES 


FRANCE  AGARD  NON  CLASSIFIEES 

Telecopie  0(1)55.61.22.99  •  Telex  610  176 


L’ AGARD  detient  un  stock  limite  de  certaines  de  ses  publications  recentes.  Celles-ci  pourront  eventuellement  etre  obtenus  sous  forme  de 
copie  papier.  Pour  de  plus  amples  renseignements  concemant  I’achat  de  ces  ouvrages,  adressez-vous  a  1’ AGARD  par  lettre  ou  par  telecopie 
i  I’adresse  indiqu6e  ci-dessus.  Veuillez  ne  pas  telephoner. 

Des  exemplaires  supplementaires  peuvent  parfois  etre  obtenus  aupres  des  centres  de  diffusion  nationaux  indiques  ci-dessous.  Si  vous 
souhaitez  recevoir  toutes  les  publications  de  I’AGARD,  ou  simplement  celles  qui  concement  certains  Panels,  vous  pouvez  demander  d’etre 
Indus  sur  la  liste  d’envoi  de  Fun  de  ces  centres. 

Les  publications  de  I’AGARD  sont  en  vente  aupres  des  agences  de  vente  indiqudes  ci-dessous,  sous  forme  de  photocopie  ou  de  microfiche. 
Certains  originaux  peuvent  egalement  etre  obtenus  aupres  de  CASI. 


CENTRES  DE  DIFFUSION  NATIONAUX 


ALLEMAGNE  ISLANDE 

Fachinformationszentrum  Karlsruhe  Director  of  Aviation 

D-76344  Eggenstein-Leopoldshafen  2  c/o  Flugrad 

BELGIQUE  Reykjavik 

Coordonnateur  AGARD-VSL  ITALIE 

Etat-major  de  la  Force  aerienne  Aeronautica  Militare 

Quartier  Reine  Elisabeth  Ufficio  del  Delegate  Nazionale  all’ AGARD 

Rue  d’Evere,  1140  Bruxelles  Aeroporto  Pratica  di  Mare 

CANADA  00040  Pomezia  (Roma) 

Directeur  -  Gestion  de  I’information  LUXEMBOURG 

(Recherche  et  developpement)  -  DRDGI  3  Voir  Belgique 

Ministere  de  la  Defense  nationale  NORVEGE 

Ottawa,  Ontario  KIA  0K2  Norwegian  Defence  Research  Establishment 

DANEMARK  Attn;  Biblioteket 

Danish  Defence  Research  Establishment  P.O.  Box  25 

Ryvangs  Alle  1  N-2007  Kjeller 

P.O.  Box  2715  PAYS-BAS 

DK-2100  Copenhagen  0  Netherlands  Delegation  to  AGARD 

ESPAGNE  National  Aerospace  Laboratory  NLR 

INTA  (AGARD  Publications)  P.O  Box  90502 

Carretera  de  Torrejon  a  Ajalvir,  Pk.4  1006  BM  Amsterdam 

28850  Torrejon  de  Ardoz  -  Madrid  PORTUGAL 

ETATS-UNIS  Estado  Maior  da  Forga  Aerea 

NASA  Center  for  AeroSpace  Information  (CASI)  6e  Documentaqao 

800  Elkridge  Landing  Road  ® 

Linthicum  Heights,  MD  21090-2934  2700  Amadora 

FRANCE  ROYAUME-UNI 

O.N.E.R.A.  (Direction)  Defence  Research  Information  Centre 

29,  Avenue  de  la  Division  Leclerc  «  n*®®™ 

92322  Chatillon  Cedex  Brown  Street 

Glasgow  G2  SEX 

GRECE  TIT'ROTTTF 

Hellenic  Air  Force  IDKlJUllj. 

Ak  War  CollLe  Savunma  Ba?kanli|i  (MSB) 

Scientific  and  Technical  Library  Dairesi  Bajkanligi  (MSB) 

Dekelia  Air  Force  Base  06650  Bakanliklar- Ankara 

Dekelia,  Athens  TGA  1010 

AGENCES  DE  VENTE 

NASA  Center  for  AeroSpace  Information  (CASI)  The  British  Library  Document  Supply  Division 

800  Elkridge  Landing  Road  Boston  Spa,  Wetherby 

Linthicum  Heights,  MD  21090-2934  West  Yorkshire  LS23  7BQ 

Etats-Unis  Royaume-Uni 

Les  demandes  de  microfiches  ou  de  photocopies  de  documents  AGARD  (y  compris  les  demandes  faites  aupres  du  CASI)  doivent 
comporter  la  denomination  AGARD,  ainsi  que  le  numero  de  serie  d’ AGARD  (par  exemple  AGARD-AG-315).  Des  informations 
analogues,  telles  que  le  litre  et  la  date  de  publication  sont  souhaitables.  Veuiller  noter  qu’il  y  a  lieu  de  specifier  AGARD-R-nnn  et 
AGARD-AR-nnn  lors  de  la  commande  des  rapports  AGARD  et  des  rapports  consultatifs  AGARD  respectivement.  Des  references 
bibliographiques  completes  ainsi  que  des  resumes  des  publications  AGARD  figurent  dans  les  joumaux  suivants: 


Scientific  and  Technical  Aerospace  Reports  (STAR) 

STAR  pent  etre  consulte  en  ligne  au  localisateur  de 
ressources  uniformes  (URL)  suivant: 

http;//www. sti.nasa.gov/Pubs/star/Star.html 
STAR  est  edite  par  CASI  dans  le  cadre  du  programme 
NASA  d’information  scientifique  et  technique  (STI) 
STI  Program  Office,  MS  157A 
NASA  Langley  Research  Center 
Hampton,  Virginia  23681-0001  , 

Etats-Unis 


Government  Reports  Announcements  &  Index  (GRA&I) 

publie  par  le  National  Technical  Information  Service 

Springfield 

Virginia  2216 

Etats-Unis 

(accessible  egalement  en  mode  interactif  dans  la  base  de 
donnees  bibliographiques  en  ligne  du  NTIS,  et  sur  CD-ROM) 


Imprime  par  le  Groupe  Communication  Canada  Inc. 
(membre  de  la  Corporation  St- Joseph) 

45,  boul.  Sacre-Cceur,  Hull  (Quebec),  Canada  KIA  0S7 


NATO  OTAN 

7  RUE  ANCELLE  •  92200  NEUILLY-SUR-SEINE 
FRANCE 

Telefax  0(1)55.61.22.99  •  Telex  610  176 


DISTRIBUTION  OF  UNCLASSIFIED 
AGARD  PUBLICATIONS 


AGARD  holds  limited  quantities  of  some  of  its  recent  publications,  and  these  may  be  available  for  purchase  in  hard  copy  form.  For  more 
information,  write  or  send  a  telefax  to  the  address  given  above.  Please  do  not  telephone. 

Further  copies  are  sometimes  available  from  the  National  Distribution  Centres  listed  below.  If  you  wish  to  receive  all  AGARD  publications, 
or  just  those  relating  to  one  or  more  specific  AGARD  Panels,  they  may  be  willing  to  include  you  (or  your  organisation)  in  their  distribution. 

AGARD  publications  may  be  purchased  from  the  Sales  Agencies  listed  below,  in  photocopy  or  microfiche  form.  Original  copies  of  some 
publications  may  be  available  from  CASI. 


NATIONAL  DISTRIBUTION  CENTRES 


BELGIUM 

Coordonnateur  AGARD  —  VSL 
Etat-major  de  la  Force  aerienne 
Quartier  Reine  Elisabeth 
Rue  d’Evere,  1140  Bruxelles 

CANADA 

Director  Research  &  Development 
Information  Management  -  DRDIM  3 
Dept  of  National  Defence 
Ottawa,  Ontario  KIA  0K2 

DENMARK 

Danish  Defence  Research  Establishment 
Ryvangs  Alle  1 
P.O.  Box  2715 
DK-2100  Copenhagen  0 

FRANCE 

O.N.E.R.A.  (Direction) 

29  Avenue  de  la  Division  Leclerc 
92322  Chatillon  Cedex 

GERMANY 

Fachinformationszentrum  Karlsruhe 
D-76344  Eggenstein-Leopoldshafen  2 

GREECE 

Hellenic  Air  Force 
Air  War  College 
Scientific  and  Technical  Library 
Dekelia  Air  Force  Base 
Dekelia,  Athens  TGA  1010 

ICELAND 

Director  of  Aviation 
do  Flugrad 
Reykjavik 

ITALY 

Aeronautica  Militare 

Ufficio  del  Delegate  Nazionale  all’ AGARD 
Aeroporto  Pratica  di  Mare 
00040  Pomezia  (Roma) 


LUXEMBOURG 

See  Belgium 

NETHERLANDS 

Netherlands  Delegation  to  AGARD 
National  Aerospace  Laboratory,  NLR 
P.O.  Box  90502 
1006  BM  Amsterdam 

NORWAY 

Norwegian  Defence  Research  Establishment 
Attn:  Biblioteket 
P.O.  Box  25 
N-2007  Kjeller 

PORTUGAL 

Estado  Maior  da  Forqa  Aerea 
SDFA  -  Centro  de  Documentaqao 
Alfragide 
2700  Amadora 

SPAIN 

INTA  (AGARD  Publications) 

Carretera  de  Torrejon  a  Ajalvir,  Pk.4 
28850  Torrejon  de  Ardoz  -  Madrid 

TURKEY 

Milli  Savunma  Ba^kanligi  (MSB) 

ARGE  Dairesi  Ba^kanligi  (MSB) 

06650  Bakanliklar-Ankara 

UNITED  KINGDOM 

Defence  Research  Information  Centre 
Kentigem  House 
65  Brown  Street 
Glasgow  G2  SEX 

UNITED  STATES 

NASA  Center  for  AeroSpace  Information  (CASI) 
800  Elkridge  Landing  Road 
Linthicum  Heights,  MD  21090-2934 


SALES  AGENCIES 


NASA  Center  for  AeroSpace  Information  (CASI)  The  British  Library  Document  Supply  Centre 

800  Elkridge  Landing  Road  Boston  Spa,  Wetherby 

Linthicum  Heights,  MD  21090-2934  West  Yorkshire  LS23  7BQ 

United  States  United  Kingdom 

Requests  for  microfiches  or  photocopies  of  AGARD  documents  (including  requests  to  CASI)  should  include  the  word  ‘AGARD’ 
and  the  AGARD  serial  number  (for  example  AGARD-AG-315).  Collateral  information  such  as  title  and  publication  date  is 
desirable.  Note  that  AGARD  Reports  and  Advisory  Reports  should  be  specified  as  AGARD-R-nnn  and  AGARD-AR-nnn, 
respectively.  Full  bibliographical  references  and  abstracts  of  AGARD  publications  are  given  in  the  following  journals: 


Scientific  and  Technical  Aerospace  Reports  (STAR) 

STAR  is  available  on-line  at  the  following  uniform 
resource  locator: 

http://www.sti.nasa.gov/Pubs/star/Star.html 
STAR  is  published  by  CASI  for  the  NASA  Scientific 
and  Technical  Information  (STI)  Program 
STI  Program  Office,  MS  157A 
NASA  Langley  Research  Center 
Hampton,  Virginia  23681-0001 
United  States 


Government  Reports  Announcements  &  Index  (GRA&I) 

published  by  the  National  Technical  Information  Service 

Springfield 

Virginia  22161 

United  States 

(also  available  online  in  the  NTIS  Bibliographic 
Database  or  on  CD-ROM) 


Printed  by  Canada  Communication  Group  Inc. 

(A  St.  Joseph  Corporation  Company) 

45  Sacre-Cceur  Blvd.,  Hull  (Quebec),  Canada  KIA  0S7 


ISBN  92-836-0044-4 


